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

I code C# for a living

[carpe_noctem]

...and let me tell you, java doesn't have to do that much to "catch up" to it.

Re:I code C# for a living

[carpe_noctem]

Maybe I just don't grok OO design, but the whole language is really abstract. Nothing seems to tie together to anything else in any sort of logical fashion, and it takes hours to figure out how anything works.

Meh, that's just my take on it. And it would appear that my opinion is officially modded "troll". Oh, well. =/

Re:I code C# for a living

[Westley]

So if you find C# abstract, where *exactly* is Java better, as a language? Or were you actually comparing the libraries? (Which bit of C# itself took hours for you to figure out?)

Personally I find them reasonably equivalent, but C# has a few advantages (properties, delegates, events) and the .NET library has had fewer iterations so is less internally inconsistent than the Java libraries at the moment.

Re:I code C# for a living

[LnxAddct]

I code in java on the side for some small business apps. I've also coded in C# and have used all of the MS Visual Stuido nonsense. Both languages are at a level that you can do just about anything with one that you can do with the other. So the deciding factors come down to really which is a better platform to develop on and cross platform compatibility (in some cases the latter isn't an issue, but it is for me). As far as IDE's go,I don't get what people like about Visual Studio, especially VS.net. I enjoyed VS 6.0 much better the VS.net, regardless I have since moved to a strictly open source platform and only use Windows for testing. When I did do C# coding, I preferred using vim or Sharpdevelop. I really can't stand VS.net. Anyway, Java, imho, has superior IDEs (some may argue that IDEs reinforce bad programming, etc..., but if used *correctly* they can significantly increase productivity) Eclipse puts Visual Studio to shame in many areas. Eclipse is an amazing IDE and made programming fun again. Another great IDE for Java, that puts great focus on GUI dev, Web App dev, and Mobile phones, is Net Beans. Both IDEs have very nice integrated features with a great tool selection and good plugin frameworks. I use both interchangeably depending upon specific tasks and projects. So in my oppinion as far as having a good platform to work on, Java is superior. Next is cross platform compatibility. Although Mono is making leaps and bounds, Java wins hands down on this. It gives my customers more options and major open source software foundations like the Apache foundation actively work on many java based enterprise applications. This allows my customers to also have low start up and implementation costs.No real need for further discussion on that. Another area where I prefer java is for distributing applications via WebStart. It makes life very easy, in many areas including maintenance and deployment. This is just my 2 cents. I don't really see why anyone would use C#, I mean they took Java and improved, and now Java has taken both its past and C# and improved itself :/
Regards,
Steve

Re:I code C# for a living

[CaptnMArk]

C# vs Java, mostly a tie (c# good: ref and out parameters, indexers, foreach; c# bad: properties, operator overloading)

c# library vs Java library: c# is much cleaner in some aspects.

VS.net vs Eclipse: no contest, VS.net is much worse.

Re:I code C# for a living

[fitten]

How exactly does it pale in comparison? What features does it have that make it better? What features does VS.NET lack?

Re:I code C# for a living

[gooser23]

Granted I've only used a few IDEs (VS6, VS.Net2002, VS.Net2003, Tornado for vxWorks, Xcode, Kdevelop & ddd), but of all VS.Net is cleanly the easiest to get things done in overall.

I did not find Kdevelop or ddd particulary more useful than vi other than having been weaned on VS6 I am simply more comfortable with a GUI than a tty.

Xcode does every part of project management and structure more correctly than VS in my opinion. The idea that your source tree is separate from your targes and that your targets are separte from your executables just makes sense. There's a lot less special cases this way.

Tornado for vxWorks (ver 2.2.1 IIRC, its been some time since I used it) is a poor copy of VS6 -- possibly more correctly VS5 or 4, but I've never used those. The one thing that Tornado got right is the remote debugging (e.g., you build a vxWorks system, load it onto your embeded system, and you can debug through your app via ethernet, serial port, or a local pci bus). In fact, without the remote dubugging I would have considered Tornado to be utterly useless.

The things that set VS apart is its build styles and debugging features. Xcode could catch up on the both of these (esp. the build styles), but I'd say gdb has a long way to go to be on the same leve als VS's debugger. Its really nice to be able to add new code, change existing code, and arbitrarily set the execution pointer. Really the 'advanced feature' I've figured out how to replicate on gdb is changing a variable's value, but even this feels rudimentary to how in VS you can arbitrarily change the contents of memory directly.

So, in short, what I like about Visual Studio is its build styles and debugging capabilities. But I do think Xcode 1.5 is better thought out, just not as polished in these two areas.

I should add that all this does not apply to any APIs of the aforementioned products, in which I would agree with you (having used MFC, ATL, COM and WIN32), I don't see why informed person would choose these over the alternatives (wxWindows, stl, boost, Cocoa) if they had a choice.

Re:I code C# for a living

[iezhy]

Java has checked exceptions

exception management in c# is so painful without them

Re:I code C# for a living

[WebfishUK]

One of the reasons that Fortran has such reusability is because everything was an array. It was eaasy to use some elses function I just had to re-organise the elements in my array (you soon build a library of functions to do this that you use a lot). The problem with OO languages is that you get complete ability to define clever objects which you (and me) always assume will be the focus of everyones life. It becomes very difficult to reuse stuff not from a coding point of view but because the object you have to work with is never exactly what you wanted.

Re:I code C# for a living

[swilver]

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 :)

Re:I code C# for a living

[Three Headed Man]

Every time I see "C#" I always think of a funny comment from a poll, maybe 6 months back, of "What do you call #?" The options given were "Sharp, Hash, Pound, Channel, Tic-Tac-Toe sign" etc. The funny comment was "I call it the 'rap' sign. You know, as in C#"

Re:I code C# for a living

[shatfield]

It becomes very difficult to reuse stuff not from a coding point of view but because the object you have to work with is never exactly what you wanted.

This means that you just subclass the object that doesn't quite fit your needs and either extend or override the original functionality. That's the beauty of OOP -- plan well, and you're options are unlimited.

Re:I code C# for a living

[cakoose]

C# vs Java, mostly a tie (c# good: ref and out parameters, indexers, foreach; c# bad: properties, operator overloading)

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.

Re:I code C# for a living

[SnprBoB86]

Out parameters are kind of neccesary if you have ref parameters. They are basically ref parameters that MUST return a value and because C# requires all variables be initalized, if you have ref, you must have out and you must force all ref params to be initalized before being passed in.

Out parameters are mainly for use with API calls that return strings and such in reference paramters.

As far as I know, nowhere does the base class library use out paramters (I am sure there is somewhere, but it is probably obscure or related to native interop).

Re:I code C# for a living

[GCP]

And I was a member of one of the JCP expert groups that brought you Java 5.

java doesn't have to do that much to "catch up" to it.

Stated another way, Java 5 is still behind C#, to which I would agree.

As to how far behind, that depends on what you value. Java's event handling/callback design is atrocious compared to the convenience of delegates. I would much rather pass a single method called OnAccountOverdrawn()to the event notifier than the Java style of making the whole class an instance of some interface, implementing stubs for all the useless methods of the interface, then implementing the one useful method--which will have a useless name like DoAction() that you can't change, then passing the object that contains the DoAction() method to the event notifier.

And for many things such as generics, autoboxing, enums, etc. (I don't recall which ones specifically), there are actual semantic differences in the virtual machine for C#, whereas Java's knockoff versions are just syntactic sugar for the writing out the equivalent source code yourself. I AM in favor of syntactic sugar, but having the actual semantics available in the underlying runtime gives you additional advantages.

Java's great advantage is its ubiquity, which is also an impediment to improvement. Sun's position was that it was pretty much finished with language improvements after Java 1.1 and would thereafter concentrate on libraries that would run on existing JVMs. New JVMs might run the code even better, but the old JVMs would still run it.

Microsoft knew they had to do better, or nobody would switch. They did a lot of things better, and they seem committed to doing more, even if it means obsoleting their existing VMs. They have far more control over The (One) Platform and seem quite willing to make improvements to C# and the other .Net technologies that will require a VM upgrade.

One catgegory of improvement they seem interested in is a way to make dynamic languages, like Python or Lisp, work REALLY well. Another is support for functional languages like Haskell or OCaml that have special needs of their own.

And if they do it well, (my speculation now), they could even add some of the attractive features of those languages, languages I like more than C#, to C#, widening the gap with Java.

Java might have a very hard time keeping up with C# improvements while anchored to existing runtimes, and letting go of the anchor would seriously impact its ubiquity, which is one way in which Java is vastly better than C#.

I don't think it's a given that Java is going to catch up to C#. But if Mono and/or DotGnu don't succeed, it may not matter as Windows fades away (which I believe it will).

Re:I code C# for a living

[angel'o'sphere]

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

Re:I code C# for a living

[elgaard]

>Can somebody explain what you mean by the covariant and contravariant things.

In an OO language with objects and types we may say that a type, ST is a subtype of T.
The meaning of this is that an object of type ST can be used where an object of type T is expected.

Objects of type ST can have more operations (functions) than objects of type T, but it must have the same operations as objects of type T. These operations must have the same number of arguments and results as operations in T. But the arguments to those operations does not necessarily have to be the same type.

Say T has an operation (signature): ft(a1:Ta) -> (r1:Tr)
ST must then have an operation: ft(a1:STa) -> (r1:STr)

Results are easy. A program that do:
foo:T
bar:Tr = foo.ft(...)

requires that bar have a type that are a subtype of Tr therefore
STr must be a subtype of Tr.

Arguments are more tricky: A program can do:
foo:T
ba:Ta ...=foo.ft(ba)

foo can be of type T or ST therefore ba must work as an argument to ft in objects of type ST.
This means that Ta must be a subtype of STa.
This is contravariance.
One consequense is that Array[T] is not a subtype of Array[ST] or the other way around. Because Array (or any other collection) must have both a set(T/ST) and get->(T/ST) functions and because of contravariance T must be a subtype of ST and ST a subtype of T, i.e. T==ST.

It does not work quite like that in Java, because in the foo.ft(ba) the "ft" function defined in the base class, T, would be used.

But in Java an array of a supertype is considered a supertype of an array of the subtype.

Object[] objects = new FooClass[10];
objects[0] = new Object();

Will give a runtime ArrayStoreException

Re:I code C# for a living

[k8to]

Yes, OOP works beautifully, all you have to do is predict the future.

Re:I code C# for a living

[kaffiene]

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.

I disagree. Properties increase the number of entities you have to deal with - there used to be member values and member functions, now in C# you have memnber functions, member values and member properties. Many times in C# I find my code breaking because what I thought would be a property is implemented as a getter and setter or vice versa. This ends up wasting your time reading documentation to find which way getting the value is implemented. This is never a problem in java, it's always getMyVal();

The other thing with properties is that they look like fields, but don't work that way, for example, if B and C are implemented as properties, then this will not compile under C#:

A.B.C = someVal;

I beleive it's because the A.B bit puts the B value on the stack and assigning a value to it doesn't get back into A. At any rate, it doesn't work and to me it's pretty obvious that it should.

Function pointers and anonymous functions. This has got to be the biggest improvement over Java.

Again, I disagree. Function pointers are not a good feature. Implementing an interface in Java (which is the equivallent process to function pointers in C#) is better because the interface expresses a contract and the naming of the functions involved reflect that contract. What I mean is that when I see this in Java:

public void actionPerformed(ActionEvent ae)

I know that I've found a method fullfilling the ActionListener contract - what's more, the class involved will say implements ActionListener so the existence of the contract is explicit. With C# I could find a function like so:

public void myfunc(object sender)

...And that could be the end point for any old connection between classes. The good thing about OO is that the methods on classes represent the communication contract between entities. This is an important API and should be as explicit as possible, not virtually rendered anonymous as in C#

And in the end, the obvious difference between Java and C# is that Java is everywhere and open and C# isn't. Yes, .NET has *parts* of it as an ECMA standard, but ECMA standards *DONT* exclude technology which is patent encumbered. Meanwhile there are dozens of open source Java implementations and Java exists on pretty much every machine under the sun.

Varargs?

[American AC in Paris]

That sounds like it should be some Adams-esque race of semi-competent space pirates...

All in it together

[Doc Ruby]

How about a cross-compiler that takes advantage of this vendor competition in cooperation to combine both communities of programmers into one pool targeting either virtual machine?

Re:All in it together

[Gherald]

> How about a cross-compiler that takes advantage of this vendor competition in cooperation to combine both communities of programmers into one pool targeting either virtual machine?

And in other news, Microsoft decides to bundle Cygwin with Longhorn...

(ok so maybe Mono could do Java, not that I understand why they'd want to)

Re:All in it together

[Cannelbrae]

Quick, someone email Bill. Slashdot wants Java.NET. ;)

Re:All in it together

[jungd]

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).

Re:All in it together

[VertigoAce]

J# sounds a lot like the second option. It is sort of like coding in Java but using the .Net framework. It's not really intended for anybody to start new projects with, but instead as a stepping stone between Java and C#.

Re:All in it together

[mortenmo]

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.

Re:All in it together

[achacha]

The designers try to avoid multiple inheritance since they are aiming Java and C# to the bottom 85% of the programmers and multiple inheritance is too complex and way too many weak programmers do not understand how it works and create problems with its misuse. Give an unskilled worker a jackhammer and you can expect a call from your local utilities company. Just my observation...

Re:All in it together

[Corngood]

The can and do, he doesn't know what he's talking about. You don't need multiple inheritance to make circular inheritance.

Re:All in it together

[Fnkmaster]

Yes, but are you sure it's stepping you in the right direction?

Re:All in it together

[fitten]

Interfaces are your friends. Most of what people use multiple inheritance for can be achieved by using multiple interfaces.

Fix the link

[eissimuf]

Fix that first link. It shouldn't have a slash at the end:

http://java.sun.com/j2se/1.5.0/docs/relnotes/fea tu res.html

Re:Fix the link

[eissimuf]

omg, it hates me... trying one last time Java 1.5

Re:Fix the link

[AKAImBatman]

You should have seen the original story from the future. It said, "Sun releases Java". Pretty short intro. :-)

It turned out that the submitter (or someone editing the article) lost the rest of the link when they submitted it. Thus the source code showed:

Sun releases <A href=" http:// Java 1.5</A>

(lots more text here)

I'm confused

[abrotman]

Where's the story? Or is this just one person's interpretation of Java vs. C#?

Learn to write?

[Palshife]

I've never seen so many grammatical errors. You win.

Re:Learn to write?

[American AC in Paris]

Don't think of it as loaded with grammatical errors. Think of it as Compiled with (0) errors, (472) warnings ...

Re:Learn to write?

[Tumbleweed]

I'd love to see his version of Hello World. :)

Re:Learn to write?

[mog007]

Maybe he takes Microsoft's stance on the issue...
"It compiles... ship it!"

what about...

[syrinx]

and you're foundations in OOP is rock-solid

What about our foundations in English?

Re:what about...

[yoyhed]

You missed another:

and you're foundations in OOP is rock-solid

Come on, people. Conjugate.

flamebait

[Bert690]

It's times like this when you'd REALLY like the ability to mod the story itself as troll/flamebait!

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 ---

Re:flamebait

[oniony]

Fully agree. The guy doesn't know what he's talking about. Java has much more support in the industry, .NET in the enterprise is currently painful. The tools are barely usable (Visual Studio debugger on a large application, anyone?) plus he makes some fundamental errors in the list. .NET does not support auto-unboxing for example (at least not .NET 1.0 or 1.1).

Re:flamebait

[jeif1k]

.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.

Re:flamebait

[mrogers]

Large applications written in Java are bugs. ;-p

Re:flamebait

[Fnkmaster]

Well, I think some people might be trying to help Java compete on the desktop. Have you heard of SWT and Eclipse? It does have IBM behind it. I agree that Sun seriously dropped the ball with desktop Java for years, so nobody used it for that. As for developing desktop apps in C++, yes Visual Studio 6 was a very solid choice. Is VS.NET as good? Many people seem to think not. I haven't spent enough time with it to know, and don't really have the desire to.

Re:flamebait

[mabinogi]

No specialised debugger for me - just the built in debugging support in Eclipse.
Or even JBuilder.
And I assume all the other IDEs have debuggers built in too.
And there's heaps of stand alone ones too. There's bound to be one that suits your needs.

hmmm....googling for "java debugger" gives a nice long list of java debuggers.

".net debugger" gives you a page full of problems with the VS debugger - headed with "The VS7.X Debugger doesn't work, What can I do?"
and one or two links that appear to be 3rd party debuggers - but aren't related to .NET at all.

I'm pretty sure that says something...I'm not quite sure what though....

Re:flamebait

[kaffiene]

Java on the desktop is superior to C#. .NET doesn't even have a table component for christ's sake (Datagrid doesn't count, it's only for use with a DB)

Cue the zealots on both sides

[JUSTONEMORELATTE]

Why again can't I mod a story as -1 Flamebait?

--
I'll pay you $10. Really.

Java 1.5 vs c# 2.0?

[hpj]

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).

Re:Java 1.5 vs c# 2.0?

[Anonymous Coward]

Comparing an unreleased version of C# to the available version of Java is just stupid. Further, with no mention of the provided API any discussion is a waste of time. While JAVA offers a bloated API, it is extensible and great for programming, unlike dot NET 1.1 which seems to be an attempt to build OO on top of a procedural framework that doesn't provide the programmer with the same level of flexability. The other thing to consider is that dot NET means normally a purchase of Visual Studio, while JAVA normally means a free download of the JSDK and JCreator. Also IMHO Java doc is much better then the stuff that comes with dot NET. The rest is rant......

Comparing a released software product that is available almost for free to an unreleased product that costs hundreds of dollars is just dumb. Where is the story here?

Re:Java 1.5 vs c# 2.0?

[swilver]

C's implementation of abstracting machine code is just a compiler hack, the underlying machine code has not changed. The only benefits are some compiler errors and warnings and not performance and storage efficiency that real machine code can offer.

Seriously, I couldn't care less about better performance. I care about being able to avoid probably 75% of all casting that goes on in our 10.000+ source file project and being able to specify our API even tighter and catch more problems before it hits our customers.

I just wish Sun had done this 3 years ago, but better late than never.

Re:Java 1.5 vs c# 2.0?

[jeif1k]

But will you be releasing those apps before dotNet 2.0 is officially released

Well, people seem to be reluctant to release code for Java 1.5 as well because there seem to be some backwards compatibility issues as well.

To me, it doesn't get interesting anyway until gcj and Mono have the features, and both of those are still several months off.

What Language

[jcook793]

What language was this post written in? Amazing.

I want functions

[Tablizer]

I want actual functions, not "activity objects". Almost everyone, except for the extreme OO zealots, agree that OOP is not necessarily the best approach to every problem.

Re:I want functions

[e2d2]

There are people still arguing against OOP? How quaint.

Why not argue against managed memory while you're at it.

YES THIS IS A TROLL

HITLER

Too bad we can't mod articles

[MojoRilla]

This would get a -1 Flamebait.

My feeling is that these features are good news. There should be no gloating on the part of C#, it was clearly built on Java's coattails.

Competition is a great thing, ain't it?

Re:Too bad we can't mod articles

[Slime-dogg]

I wouldn't give Java the credit for C#. If anything, it was Delphi that C# was built upon. The only thing that C# "borrowed" from Java is the idea of a VM, and even that functions in a different way than the Java one.

From the Horse's Mouth - might make more sense

[Anonymous Coward]

Maybe it makes more sense to listen to what the tech lead of Java 1.5 had to say here.

(= Calvin Austin)

Flaws in both Languages

[Dante Shamest]

Neither are open source.

Both require virtual machines.

Despite being marketed as portable, but have portability issues. Java is not backward compatible with older versions. C# has problems with porting some of the graphics stuff to Linux.

We don't really need them. PHP/Perl serve my needs on the web/server side. C++ and Python server my needs on the desktop side.

They're closely tied to their respective companies.

If you think this is flame-bait, check out this article's title.

Re:Flaws in both Languages

[scovetta]

You use PHP/Perl on a server? For something other than adding phpbb to your homemade website? Sorry, but PHP/Perl serves a purpose, and so do Java/C#, and they two are almost mutually exclusive.

For enterprise-grade web-applications (not hacks), it's .NET or Java. For real applications, it's either .NET, Java, or C++.

End of story. Don't argue with me, just accept it.

Re:Flaws in both Languages

[nat5an]

Who modded the parent up? The post is woefully inaccurate.

1. What exactly does it mean if a language is "open source?" Surely, the specification is available for free. If you wanted to, you could write a lexer/parser/compiler without paying anything to Microsoft/Sun. Do you mean that the tools provided by the companies aren't open-source?

2. C# doesn't "require" a virtual machine any more than Java "requires" a virtual machine. One could write a native compiler for both. Additionally, in fact, Microsoft's .NET implementation does just-in-time compilation of the .NET assembly generated by the C# compiler (the bytecodes, basically), so it doesn't actually run inside of a virtual machine, nor is it interpreted. Since Sun's javac is supposed to generate portable bytecodes to run on different architectures, they decided to use a VM to avoid having to write a thousand different JIT compilers.

Neither of these are inherent weaknesses in the specifications of the languages, they're implemetation details. Since this story is supposed to be about new language features in Java, I don't see how bitching about Microsoft/Sun's implementations is really relavent.

Re:Flaws in both Languages

[X]

Let's take these one at a time here:

Neither is open source. Languages can't be classified open source, because they aren't programs. Certainly both languages have non-open source implementations, but they also have open source implementations.

Both require virtual machines. Well, I guess it depends on what you mean by a virtual machine. Technically even the C runtime is a virtual machine. That being said, both Java and C# can be compiled to native code, bypassing the need for the JVM/CLR.

Despite being marketed as portable, but have portability issues. ROTFL! Yes, perfect portability isn't possible. However, both languages are amazingly portable considering their extensive feature sets.

We don't really need them. Really, when you think about it, we only really need C. PHP/Perl/C++/Python are really all flawed languages as a consequence. ;-)

They're closely tied to their respective companies. This is more of a perception problem than a reality problem. I can do development in either language without getting involved with either company.

Re:Flaws in both Languages

[greg_barton]

Neither are open source.

Don't want to get into a religious argument here. Being 100% open source is not always a benefit.

Both require virtual machines.

Really?

Despite being marketed as portable, but have portability issues.

"They're not perfect, so toss 'em out!" Great argument...

We don't really need them.

Yeah, we don't really need Perl of PHP either. I do all of my web pages in assembler.

They're closely tied to their respective companies.

Really?

Re:Flaws in both Languages

[PCM2]

Short answer is that portability is not the purpose of the virtual machine for C# (and for many people, it's not the purpose of using the Java virtual machine).

Re:Flaws in both Languages

[Teckla]

# Neither are open source.

How can you "open source" a language? Are you talking about compilers themselves being open source, or what? The language specifications for both Java and C# are trivially available for anyone that cares to look at them.

# Both require virtual machines.

This is simply not true. For example, there are at least two Java compilers that produce native executables.

# Despite being marketed as portable, but have portability issues. Java is not backward compatible with older versions. C# has problems with porting some of the graphics stuff to Linux.

I work for a software company whose products target half a dozen operating systems, and based on ample experience, I can say using Java has simplified our life remarkably in terms of portability. Is it perfect? No. But just because it isn't perfect doesn't mean it's not a huge step forward in terms of making it easy to write portable code.

# We don't really need them. PHP/Perl serve my needs on the web/server side. C++ and Python server my needs on the desktop side.

We don't really "need" PHP/Perl/C++/Python either, now do we? This comment is just plain meaningless.

# They're closely tied to their respective companies.

With all due respect, this is about the only thing that makes sense in your entire post.

Re:Flaws in both Languages

[Hezaurus]

1. What exactly does it mean if a language is "open source?" Surely, the specification is available for free. If you wanted to, you could write a lexer/parser/compiler without paying anything to Microsoft/Sun. Do you mean that the tools provided by the companies aren't open-source?

Java is 'open source'. Everything: JDK classes and the virtual machine, all are there for everyone to see. Sun owns the Java trademark and is in control of what language features are in and what are out.

.NET is not open source. Correct me if I'm wrong but I think that the CLR source isn't available. C# is a standardized language. That means that 'theoretically' other parties can influence the direction of the language in the future.

.NET implementation does just-in-time compilation of the .NET assembly generated by the C# compiler (the bytecodes, basically), so it doesn't actually run inside of a virtual machine, nor is it interpreted. Since Sun's javac is supposed to generate portable bytecodes to run on different architectures, they decided to use a VM to avoid having to write a thousand different JIT compilers.

Sun's Java VM has had JIT compilation already in the last millennium. Java is not interpreted, it's native code just like your regular C. HotSpot compiler compiles those pieces that get the most action and interprets those that don't benefit from compiling.

CLR and Java VM are essentially the same thing. CLR is more flexible (it supports more languages, even though the list of currently supported languages is actually bigger for Java VM) and you can mix different languages for the same project. They both have advanced garbage collection schemes and both run 'inside' a virtual machine, although in C# you can 'step outside' (unmanaged mode) to do your own memory management (which is a big bonus for some projects).

Since this story is supposed to be about new language features in Java, I don't see how bitching about Microsoft/Sun's implementations is really relavent.

Duh!

Re:Flaws in both Languages

[scovetta]

As soon as people mention "enterprise-grade web applications" it's time to skip to the next thread. These people live in a little world that's been built for them by small minded project managers, clueless clients, and a university programming course that's been bought and paid for by a large corporation (usually Sun Microsystems).

I take exception to that. Just because you can't do it doesn't mean that it can't be done. Maybe where you're from, Sun runs things, but here, it's the business-- how can you get the job done better and faster? And Java has proven to be a useful tool, when used by competant programmers (not Learn Java in 21 Days type).

I'll try to make my case for "enterprise-grade web applications". Such an application needs the following features:

1. Does what the customers want
2. Secure
3. Database-driven
4. Clustered/clusterable
5. ***Maintainable***
6. Performs well
7. Integrates with other systems
8. Deliverable by the deadline

It's #5 and #8 that are hard to come by. As for maintainability, I see Perl as a Write-Once language, with PHP only slightly better. Java/C# are much easier to maintain because (a) their syntax is not prone to being overly compact (read: unreadble), and (b) the number of people who can maintain Java applications is probably much larger than those who can modify your Perl app.

You advocate Java and slam PHP in the same post? Both of these languages belong in the same beginners class.

Where do you work that Java is considered "beginner"? Have your company actually produced applications?

Why is there a C# advertisement on /.?

[Cloudgatherer]

Seriously, this looks like an ad for C#, a bunch of claims with very little support/evidence for those claims.

I've worked on C# and Java projects. As far as I'm concerned, C# = MS Java. MS could not control Java, so they abandoned support for it and built thier own "version." It's really a rinse & repeat cycle for MS: see successful software, build own version of said software to try to take over that market as well.

Re:Why is there a C# advertisement on /.?

[jrumney]

I've worked on C# and Java projects. As far as I'm concerned, C# = MS Java.

Ditto. I'd go so far as to say that .NET has some of the same bugs as the MS JVM and class libraries, especially in the networking support, where Java is streets ahead.

templates

[minus_273]

After templates (generics) come out in a few months, i dont expect java to have an easy time catching up.Personally, I really miss templates from C++ and would drift over to the camp that offers it.

Corrected URL

[waynegoode]

The first link does not work. For the few who might not notice that the problem is the extra / at the end, thep link should be this.

Perhaps /. will correct the error. I emailed the editor when the story was in preview, but it was too late.

I call bullshit

[The Bungi]

There is no apparent point to this "story". It's full of grammatical errors and obvious flamebait arguments (flamebait in the context of the slashbot groupthink). What, "C# is teh roxx0rz and Java.. well, I forgot teh point I was makeing for Java"? "The open source crap argument"? Way to go.

Here's my theory. Along with the ubiquitous slashvertisements and the Microsoft-bash-of-teh-day barrage posts, these are a perfect opportunity to create a story that will generate 1,000+ comments and ten times those many page views and ergo ad impressions.

C'mon, C# vs. Java? Outside of "RIAA sues 86 year-old grandma", "We hate Bush, let's talk" and "Microsoft patents KDE" there is no better source of inflammatory material in the dorkosphere.

Sad, really.

the crap argument

[iamchaos]

Is this article flamebait? Maybe I am just misunderstanding when he says:

"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..."

Which "crap" argument is he talking about? I assume he means that when using those languages you have thousands of directions to go for help in howtos, docs, tutorials, books and of course the loving #perl. I normally would not reply to something like that, but I took offense. Yes I love those languages. They all have strong points and make life fun when coding. I have support and have never had to rely on a company to provide said support. Oh yeah, and I write enterprise software with the mod_perl crap everyday of my life. Thanks.

iamchaos

Re:the crap argument

[killjoe]

"Really Good Ide. "

Eclipse supports most languages including python, php, perl and ruby.

"API."

Perl, Python, Ruby and PHP have enourmous libraries to make whatever you are attempting easy.

"Consistency. "

The languages I have mentioned have been "pretty consistent". No language is completely static and each language is trying to improve the best way they know how but they have all kept backwards compatibility pretty good.

"Open source. This is not an argument. In fact, for enterprise world, open source sounds much more problematic than any of good old microsoft solutions."

Well this certainly explains why nobody is using mysql, linux, apache, bind, jboss or any other open source project in any enterprise whatsoever. By golly I think you have something here. Which leads me to.

"They are GUARANTEED to receive support, "

Gee only if there was one or two companies who provided support for open source projects. Too bad you can't buy support from companies like IBM, Novell, RedHat, Mysql etc. Wouldn't that be cool if you could buy support for open source projects.

BTW I am happy that MS provides GUARANTEED support. All those people who bitch about the crappy MS support and documents are all probably liars or open source racist hippies who enjoy dirty jokes.

Version

[xPhoenix]

So which version number is it? Java 2, Java 1.5, or Java 5? Someone should teach these guys to count before they start coding!

Optimization models

[scumbucket]

Java has a few advantages over C# in optimization. It's very easy to analyze Java programs to be certain that certain memory locations absolutely will not be modified. That's much harder in languages with native pointers. Those invariants allow you to compile out certain calculations that would have to be done at runtime in a C# program. You can even start spreading loop cycles over multiple CPUs, but I'm pretty certain that the present JVMs aren't that smart.

Re:Optimization models

[Headius]

Several JVMs use an m:n threading model (such as BEA's JRockit) that allows individual Java threads to be handled by different processor threads; this results in some extreme scalability, but obviously adds complexity to the JVM (since it is now required to manage both "green" and "real" threads). I don't believe either the .NET VM or Mono suppose m:n threading (yet).

FYI.

Re:APIs

[Palshife]

XML Parser

You mean like JAXP and JAXB?

Mistake

[ajs]

I'm not pleased with the "catch-up" game that Java is playing here. Java was a fairly nice middle-ground betweeen high and low level programming, and what appears to be an effort to become a high level language is rather ominous for those who are interested in testability and performance in Java.

This, BTW, is why you don't want your language to be controled by a company which in turn has a marketing-driven bottom-line. The idea that two languages could co-exist with different target audiences is nonsense to marketing droids, but perfectly reasonable to someone like Guido van Rossum, Larry Wall or any of the other maintainers of truly open-source languages. Open source isn't the only way to maintain this focus, but in today's marketing-driven world, you aren't likely to see too many Bell Labs-like organizations putting out languages like C (which was semi-open source, as was Unix). Java and C# are probably much more typical.

Re:Mistake

[Sanity]

Java was a fairly nice middle-ground betweeen high and low level programming, and what appears to be an effort to become a high level language is rather ominous for those who are interested in testability and performance in Java.

Generics improve testability because they largely eliminate runtime ClassCastExceptions. I haven't seen any evidence to show that any of these features impose a performance penalty. Most just make the developers life easier by saving them from repeating common code patterns.

This, BTW, is why you don't want your language to be controled by a company which in turn has a marketing-driven bottom-line.

Yeah, because hardly any companies are driven by their bottom lines...

Re:Mistake

[WaterBreath]

I think you're misunderstanding the nature of generics. Generics don't allow rock and paper objects to be stored together in the same collection. (No, that's what pervasive base classes such as Object in Java, C#, VB, etc. allow.) Generics allow you to write one class and use separate instances of that one single class to create, at run-time, type-safe rock collections, and paper collections, and scissor collections, etc., etc.

Of course that is merely the tip of the iceberg of the power of generics. C++ templates are a Turing-complete language in their own right, and when used correctly can do many of the things LISP programs can do, except executed at compile time.

Re:Mistake

[blowdart]

If we're supposed to have a collection of rocks, what the heck would paper be doing in there? More often than not, reasonable coding should prevent this

That is not what generics do, that's what your base collections of type object does. Generics (at least in c#) allow you to write templated code like

class List<T> {...}

where T is the type parameter. it actually comes time to create a List object, you say List or List. Now your list is a type safe list of ints or Customers, instantiated at runtime. You cannot mix ints and Customers in the same list.

The Java implementation is a compiler hack. It casts everything to objects, so in theory you could mix because it's just a compiler trick. Worse because everything is really an object you can't reflect over the List and work out what type it is a list of.

Re:Mistake

[Fnkmaster]

Hmm, I just found this bit, admittedly from the lead architect of C#, so I'll take with a grain of salt, but if this is true, it's a bit lame (I also found this, which is from a somewhat more trustworthy source). Damn.

Also, another piece from Bruce Eckel here. This is even more clear in its skewering of Java Generics. It really sounds like Sun dropped the ball on this one.

Re:Mistake

[cakoose]

The CLR VM knows about generics so it can safely get rid of the casts. The Sun idiots chose not to modify the JVM bytecode to accomodate generics, so the casts need to be there. You don't see the casts because "javac" inserts them for you, but they're still in there, doing what they do best: kill performance.

While the 50%-70% improvement is definitely not typical, if you do some intense algorithms on collection classes, then you'll probably see that kind of speed up. Just don't expect that kind of speedup for a real-world application.

Heh

[KoolDude]

SexyFingers writes "Sun released Java 1.5...

The ultimate question is... how did you get those sexy fingers ? Java, C# or... Pr0n# ?

Re:Only Microsoft

[Anonymous Coward]

No. Checked exceptions were an interesting experiment that turned out to be a bad idea. I won't rehash the arguments here (for a reasonable example, search for Bruce Eckel's writings on the topic), but when the ivory tower of checked exceptions meets the real world of deadlines, something has to give.

I've no plans to use C#, but it's something they definitely did right.

Re:APIs

[SnapShot]

I use DOM within XML as well as the MessageDigest using the MD5 algorithm every day. So I'm letting you know...

Or, is your complaint based on the fact that the libraries that underlie the XML and Security algorithm API's can be swapped out? To me, that's a feature not a bug but YMMV.

AVP

[pizza_milkshake]

It's just like Alien vs. Predator:

whoever wins, we lose.

Re:Sounds a lot like religion

[jayminer]

I code C# for a living, so according to your definition, sold (or more appropriately rented) my soul to the devil. (This does not change the fact that I personally prefer free/open source technology. My PDA, my media players, my home operating system are all free/open source based.)

Java is not any more closer than C# to open source technologies. Sun doesn't like open source, just as Microsoft.

It's a very well known fact that Java has been a base (or in other words "the" figure) for Microsoft while developing C#, but that does not imply that "Java is good, C# is bad" or vice versa.

I would be happier personally to code in Java, but professional life yields to disqualify who resists new technology.
Your choice of programming language is not your religion, and it can change continuously through your life. Just like your operating system.

Re:APIs

[Moe Yerca]

MD5 is native... java.security.MessageDigest.

A quick Google for "java MD5" gives a code example in the first hit, http://www.bombaydigital.com/arenared/2003/10/10/1

Think before you whine.

IIS vs J2EE Servers

[knitterb]

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.

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 .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).

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 .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! :(

Re:IIS vs J2EE Servers

[nuggetboy]

Nothing groundbreaking? What about DataGrid1.DataBind() or built-in viewstate management? I love it to bits when I think back at how horrible stuff like that was in PHP.

I see your point, but those are features of the .NET framework, not C# as a language. Also, aren't these things available in JSF?

I don't know what your IIS issues are but on my win2003 servers we've not had a single problem.

You've been lucky then. We just started to have issues with our ASP applications that *only* manifest themselves with 2003.

Re:IIS vs J2EE Servers

[eakerin]

SourceSafe is free with VS and will be even better integrated in Whidbey.

He wasn't talking about source code management, he was talking about deployment packages.

In the Java world with your Servlet engine, you drop a war (which is a glorified zip) file in a given deployment directory, and the engine unpacks it, and brings the app online. That's your entire process for deploying a simple app. It includes your web pages, classes, libaries, base config, etc.

SourceSafe may be free, but my biggest complaint with it is it's poor branching, lack of proper security, and non-client-server access menthods.

I've recently switched the windows developers at work to CVS, and had them install WinCVS and TortoiseCVS. WinCVS handles the hard stuff that you do very rarely. TortoiseCVS handles the everyday stuff. It ties into Explorer and My Computer (and other file browsing areas) and allows you do normal SCM operations (checkout, update, commit, tag, branch, diff, log, etc) right from the file browser.

It's a nice package to try out if you've never seen it. CVS has it's own problems, but they're pretty easy to watch out for. Once the windows tools for subversion get a little more time under them, I'll probably end up switching our repositories over to it, for the renames, repository-wide version, and O(1) tagging/branching.

Important differences between Java and C#

[daveho]

While neither Java nor C# is truly free of being controlled by an Evil Corporation(tm), Java at least has multiple vendors, runs on a wide variety of platforms, and has an open standardization process.

Re:Important differences between Java and C#

[rabtech]

Funny, I always thought having the ECMA control and adopt a standard was "more open" than Sun's "we're open, as long as you don't propose something we don't like" process.

Maybe I'm an oldtimer, but...

[Tony]

C'mon, C# vs. Java? Outside of "RIAA sues 86 year-old grandma", "We hate Bush, let's talk" and "Microsoft patents KDE" there is no better source of inflammatory material in the dorkosphere.

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

- Tony

With C#, stuck in windoze

[JPyObjC Dude]

so if you're doing C# and you're foundations in OOP is rock-solid, there really isn't any difference whether you're coding C# or Java.

He kind of forgot that there are many programmers and customers who DON'T want to deploy their systems on win32. With Java apps, you don't have to. In fact you can choose almost any operating system and hardware. Anybody who chooses C# over Java for enterprise deployments is truly a MicroWeenie.

I much prefer my 8 processor HP UX box any day :]

Re:With C#, stuck in windoze

[pesc]

You are right. One main feature that Sun designed for Java was WORA (Write Once Run Anywhere). M$ thought this sucked. They tried to destroy that feature and got sued over it. So the invented C# instead. C# isn't WORA, it is WORM (Write Once Run on Microsoft). With C#, you are locked in again. That's the whole point with C#.

Re:With C#, stuck in windoze

[fitten]

LoL... Write Once, Run Anywhere.... good one there... Java is Write Once, Debug Everywhere. Once you commit to one JVM, you are pretty much locked in because of the incompatibilities in other JVMs. A number of groups are using C# developed apps on both Windows and Linux without any issues at all (as long as the code uses GTK#).

There are C# development environments on other platforms... Linux for example (Mono) and one can even use Rotor on other platforms. And... at least C# is an open standard.

Re:With C#, stuck in windoze

[cmorriss]

LoL... Write Once, Run Anywhere.... good one there... Java is Write Once, Debug Everywhere. Once you commit to one JVM, you are pretty much locked in because of the incompatibilities in other JVMs.

You haven't been writing many cross platform applications in Java recently have you? I've been writing large, complex applications that must run on Windows, Linux, HPUX, AIX, OS/400, and Solaris for 6 years now. When I started, your statement was true. However, this has largely become a non-issue. Throughout testing we rarely come across a bug that is specific to a single platform or JVM as long as you use a robust JVM like Sun's or IBM's.

While you still need to test on all platforms just to be sure, 98% of the bugs found are in the Java code, not the JVM.

Re:APIs

[AKAImBatman]

Let me know when stuff like an XML Parser and MD5 are native in Java.

They ARE.

XML package
MD5 and SHA support

The former has been in Java since 1.3, and the later since 1.1(!).

Honestly, Java has every feature and the kitchen sink in its core APIs. And if a feature isn't there, it's very easy to write a library to add it. That's why programmers like Java so much.

Any other features you'd like me to find for you?

Re:Sounds a lot like religion

[Glock27]

Java is not any more closer than C# to open source technologies. Sun doesn't like open source, just as Microsoft.

How do you explain that Sun provides official Java runtimes for Linux (and for that matter sells Linux boxes) as opposed to Microsoft's complete lack of support for anything except Windows?

Sun has always been much more open than Microsoft. They are also allowing open-source implementations without fear of reprisal. We'll see if Microsoft manages the same tolerance with Mono.

"One Person"... "One C# Developer"

[Black-Man]

opinion. broken link... poor grammar... this guy is a joke. He pulls out 7 new features!! What about built-in queue support?

Only thing I agree with is generics has been long overdue.

Re:APIs

[GileadGreene]

Well, let's see, javax.xml.parsers and the related packages that are part of the Java API for XML have been standard since Java 1.4. Meanwhile, javax.crypto (which includes a Message Authentication Code class that supports MD5 hashing) has also been standard since Java 1.4. Java 1.4 is the major release that preceded the one the current article is talking about, and has been out since around 2002.

So, were you trolling, or did you just not bother to keep up with Java?

Java C# porting - Lucene as example

[otisg]

It is this similarity and 'compatibility' of Java & C# that is now making it easy to port various applications between the two languages. For instance, the very popular Lucene (Information Retrieval library from Jakarta (i.e. Java)) has a very solid .Net port written in C# called dotLucene. The Lucene -> dotLuene port is fairly automated, it appears, which allows developers of the .Net/C# port to keep up with the original software written in Java.

If C#/Java continue in this direction, I think we will see many more applications that have parallel versions in the two languages.

See:
Lucene
dotLucene

Re:Static Import Bad?

[fishbowl]

"In the case of Math, where's the bad style in writing Cos(x) instead of Math.Cos(x)?"

None at all, but I cannot count the number of times I have had to change a co-worker's static members into Object methods because of a side-effect of some other change. And don't even get me started on what a nightmare static { ... } can be.

Re:So this is what...

[teromajusa]

See, you're just too in love with Python, Perl, and Ruby. I myself used to think that those were real and useful languages. Then I discovered that c# is maintained by Microsoft and I realized that they were actually crap.

Meanwhile, C++ goes nowhere

[Animats]

C++ is in deep trouble. The C++ committee is focused on additional features for templates to the exclusion of almost everything else. Strostrup has said that there's nothing really wrong with C++, and the committee buys that. So none of the huge safety problems get fixed. And buffer overflows continue to plague computing.

This problem is the primary reason that C# exists. If the C++ committee had fixed their language, we wouldn't need C#.

It's a big issue for the open source community. The publicly standardized languages have major problems, and the newer languages are controlled by single large vendors.

Re:Meanwhile, C++ goes nowhere

[scotch]

What do you propose changing in C++, exactly? A general purpose smart pointer is going to be added, BTW.

C# doesn't really compete directly with C++, it competes with Java.

Re:Meanwhile, C++ goes nowhere

[cpghost]

C++ is a great language, but it's choosy about its friends. It takes some time to master all (well most) advanced aspects, but as soon as you do, nothing beats a good C++/STL combo.

What I don't like about C++ standard, is the lack of a decent socket library that would be part of the i/o streams. There are non-portable classes for this of course, and everyone could roll their own, but it's not in the C++ standard (yet).

IMHO, one of Java/C# biggest advantages over C++ is this particular aspect. Not that it would convince me though to switch away from C++ to Java, which simply doesn't cut it yet.

For fast prototyping, I'd stick to Python, but when performance really matters, C++ is still king!

Re:Meanwhile, C++ goes nowhere

[yamla]

I'm curious, why do we still get buffer overflows in C++ code? I mean, the C++ string type and the vector container have been around for the better part of a decade now, and a standard part of the language for, what, six years? Seven years? And you can grab smart pointers from boost.

So, why do we still have buffer overflows? Is it because of the language? I think my previous paragraph shows that this is no longer the cause, and hasn't been for years. On the other hand, C++ does still allow you to make use of C-style strings, unchecked arrays, etc., so perhaps we can blame C++ because it allows you to shoot yourself in the foot, you just have to be very explicit these days. Or perhaps the problem actually lies in the hideously outdated libraries that people are using, libraries such as the ones Microsoft gives you (I'm not talking .Net here, haven't looked at that) which still inexcusably use C-style strings and generally unsafe memory management. Not that Microsoft is solely to blame, of course.

Re:Meanwhile, C++ goes nowhere

[ultrabot]

C++ is a great language, but it's choosy about its friends.

The same can be said for COBOL. I bet somewhere in the world there is a guy that likes COBOL.

What I don't like about C++ standard, is the lack of a decent socket library that would be part of the i/o streams. There are non-portable classes for this of course, and everyone could roll their own, but it's not in the C++ standard (yet).

Sockets, as an operating system specific issue, don't really have a place in the language standard. Especially for C++, which is used for embedded development etc.

For fast prototyping, I'd stick to Python, but when performance really matters, C++ is still king!

Make that "when performance really matters, and C++ can significantly improve the performance". C++ won't make your network interface or hard drive faster, for example.

Often the smart thing to do is to first write everything in Python, and rewrite speed-critical parts in C/C++.

Re:Meanwhile, C++ goes nowhere

[deadlinegrunt]

Wow. I am amazed at your opinion and wish to understand it but I have to admit I reserved to just think that you do not know what you are talking about.

[snip]
"This problem is the primary reason that C# exists. If the C++ committee had fixed their language, we wouldn't need C#."
[snip]

First, this is not why C# exists. For real reason as to why it is search the net. Enough info out there without me reiterating it.

Second, there is "nothing really wrong with C++" and the reason the committee buys that is because it is true. The language specification spells out, as a single example, that if you index beyond the end of an array or dereference a null pointer BOOM! Undefined behavior, as in may work with some sort of reasonable expectation or may unleash flying monkey demons from your spouses nose with the sole purpose of ruining your computer career.

Third, C++ is not an OOPL like Java or C#. It is a multi-paradigm langauge with support for any type of construct you want to throw at it - including shitty code regardless of paradigm.

Again, I am trying to understand where you are coming from but I just do not see your point - or more directly that your point is valid.

C++ as a language is not really lacking at this ponit. Now standardized libs, like the inclusion of the STL was to the standard, are welcome. Things like concurrency, threading, gc, GUI, etc. Yes there are plenty out there but none of them "officially" standard yet. I think this argument would support your point better, if I was understanding what you meant rather than what you typed.

And multiple inheritance is due when...?

[Anonymous Coward]

Sorry, guys but as long as you don't have that, you're not really OO.

Limitations of Generics in Java.

[miguel]

There are some important limitations of generics in
Java, which are properly addressed in C#.

For more details, you might want to read:

http://www.artima.com/intv/generics.html

C# still has a few extra niceties like properties,
events, delegates, anonymous methods and iterators.

Miguel.

Re:Limitations of Generics in Java.

[fforw]

And C# 2.0 has real closures and none of the limitations of java inner classes. No need for the "final array of one element" hack, if you know what I mean.

no.. what is this hack?

Re:Limitations of Generics in Java.

[mrright]

An anonymous inner class in java can only refer to final variables from the local scope. So you define a final array with one element to copy something out of the inner class context.

Here is a good example:
http://c2.com/cgi/wiki?ClosuresThatWorkAroundFinal Limitation

Java poor design choices

[mmusson]

My biggest beef with java right now (well Sun, really) is that they are make design decisions in the name of backward compatibility that are leading to poor design choices. Backwards compatibility is an important consideration, but it should not be used as an excuse to make poor design decisions. I use a variety of java programs day to day that only work with certain VM versions due to bugs, features, etc. It seems silly to give this one aspect such heavy consideration as if the current java versions are perfectly backward compatible today when they clearly are not.

The new generics feature is clearly patterned after C++ templates, but in the name of backwards compatibility Sun chose to implement generics using erasure. This means that a generic type loses all of its type information leading to a alot of issues including broken support for arrays. Using erasure keeps much of the potentially confusing syntax of C++ templates and virtually none of the power.

I suppose I would be less upset if the feature had a different name. Maybe something like AutoCasting (like the name AutoBoxing). "Generics" implies things that the feature does not even try to deliver. Adding true generic programming constructs to java would have been a huge leap forward for the language. Instead we are left with a toy feature that allows you to build type safe containers, nothing more. Very disappointing.

Re:Java poor design choices

[Vultan]

Agreed. Even more frustrating is that all the collections classes have been rebuilt to be based on generics. I teach at a liberal arts college, and have found Java 1.5 to be a supreme headache. It's much harder to teach than Java 1.4. I'm finding that I have to either teach intro CS students the complexities of Java generics, or I need to teach them to ignore warning messages. It's painful.

Re:APIs

[AKAImBatman]

Quick correction:

The XML APIs were part of a standard extension in 1.3. They were added to the core in 1.4. Also, I found the JavaDocs for 1.1, so here's a link to back up my statement that MD5 support has been around that long.

API talk...

[Chuck Bucket]

Funny, we were talking about the 1.5 APIs last week here at work, while talking about migrating our apps over from 1.4.x. This site Official Java Programming Documentation gives you a ton to think about. I rem when we were on 1.2...

CB*($#@

Enterprise development

[drgroove]

Last time I checked, few industries were doing enterprise development with J2SE, regardless of the version. J2EE is the preferred platform for enterprise application development (hence the 'EE', or 'Enterprise Edition', after the 'J2' bit). J2SE 1.5 is a great release, but it means little currently for J2EE developers.

The new features to Java in version 1.5 are all anticipated and appreciated by the development community, but us J2EE developers won't be able to access these new features in our apps until the official J2EE 1.5 release comes out, and the various app server vendors (IBM, BEA, Oracle, Sun, JBoss, Apache, etc.) support it in their products.

Re:Only Microsoft

[clamatius]

I've read the arguments on the topic, but I don't agree.

Relying on documentation to tell API users what exceptions can be thrown is a really terrible idea if you're trying to write server software that has to actually work. And work all the time, 24/7, not just in a demo. MS still seems to be in the mindset where their developers are mostly making client-side VB applications or tiny ASP sites.

We've had a number of cases so far where C# library methods unexpectedly threw an undocumented exception (that would most likely have been a checked exception in a Java implementation). Now, often if you were smart you'll be lucky and the exception falling through to a general handler won't break anything too badly, but other times something unfortunate will happen.

In my book, when Microsoft's fast-to-develop-cut-all-the-corners methodology meets the real world of SLAs where software actually has to work, something has to give. And yes, you can say "just use Java/Python/Cobol/whatever instead" but the point here is debating whether using checked exceptions is a good idea or not.

I'll be honest - I like a lot of things about C#. It's a good language and their IDE is also good. But deciding that checked exceptions were bad was very unfortunate.

Re:varargs

[CountBrass]

I think you've completely misunderstood polymorphism and/or varargs.

I've never, ever had to write a Java method that would have been better implemented using varargs, but I've written plenty in C and C++ in the past that would have been better written without them...

I can only think of a couple of cases in Java where varargs would actually improve matters (have a look at MessageFormat, the work around it uses to emulate varargs is painful so varargs would be great there). But I just know varargs will get horribly absued: so overall I think Java was better off without them.

Personally I think that, overall, Java 5.0 is a mistake. Metadata is already going out of fashion: Google for "metadata hell" to read why. It's a passing fad that's passing. Autoboxing/unboxing *shrug* nice when you need it, but how often do you actually need it? Generics/templates was something I missed when I first moved from C++ to Java 10 years ago: but now it feels like more unnecessary complexity.

So overall it seems to me the 1.5 changes address some limited circumstances at the cost of additional complexity; and no doubt we'll see them mis-used and abused and that will outweigh any benefit by an order of magnitude.

What they should have done in 1.5 is strip out all the deprecated crap: Sun has this habit of constantly adding layers but never actually removing the old stuff. I really would hate to be learning Java now: it's so bloody big!

April 1st?

[cthrall]

> should be the support it has behind it, in terms
> of IDE, tools, api, and longevity of the vendor

Eclipse/IntelliJ/Together
Apache/Tomcat, WebSphere, BEA
RedHat/Suse/Mandrake/Debian

All of these tools and vendors have been around longer than C# and .NET.

> 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 ---

You misspelled "FUD."

Re:Only Microsoft

[teromajusa]

"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.

Ravioli Code

[Ian Bicking]

I think the problem you are seeing is Ravioli Code; a (perhaps excessive) reaction to spaghetti code. Also Java (and probably C#) programmers seem to take Patterns too seriously as well, patterns should be descriptive, not prescriptive.

Re:Ravioli Code

[metamatic]

Similarly, object orientation should be used as a tool, not enforced as a religion. If an object-oriented API to some functionality is the cleanest and most useful, implement that way; otherwise, don't. If the best way to build something is using functional programming, do that; don't try and force the code into an object-oriented paradigm.

still very different

[jeif1k]

Don't be fooled by syntactic similarities; C# and Java are still very different languages:

• C# has value classes
  
• C# has operator overloading
  
• C# has multidimensional arrays
  
• C# has unsafe modules; in unsafe modules, you can call C functions directly (no JNI) and manipulate C data structures and pointers
  
• C# does not force you to declare exceptions
  
• C#'s generics are efficient for unboxed types while Java boxes in many cases
  
• C#'s generics are type-safe across compilation boundaries (I believe Java's are not)
  

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.

Re:still very different

[rabtech]

You are correct re:generics. The java complier just wraps all the type casts behind the scenes - the JVM doesn't actually understand generics and the bytecode can't represent them either. Generics gain you nothing except some syntax sugar. This is a direct result of Sun's refusal to modify the JVM to support generics.

C#, VB.NET, and all dotnet languages that support generics behave differently in that the MSIL can represent and consume generic types and the runtime also understands them.

For value types, a unique native version of the class is generated per each value type used. (by the JIT). Reference types share one implementation. Constraints also allow for compile-time safety to be enforced wrt generics.

Re:still very different

[Bob9113]

C# does not force you to declare exceptions

Correction: C# does not give you the option of using checked exceptions. Java has both checked and unchecked.

Checked exceptions, when used properly, are a very good thing. The point of a checked exception is: "Pardon me developer, but did you ensure that precondition X is satisfied before calling this method?" If there is a precondition that is not apparent from the API itself, the checked exception is a good compile-time method for getting the developer's attention.

That said, I have seen (and even committed) overuse or misuse of checked exceptions. Thus I can understand Microsoft's assumption that programmers aren't smart enough to use them properly.

Re:Sounds a lot like religion

[AvitarX]

If I am not mistaken MS helped Mono out on their C# implementation.

In the driver arena this the prefered solution to having a closed official impementation. I would assume it is the same for the sake of a language also.

Plenty of differences

[flakac]

Sorry, but there are still some major differences in the two. I've looked at the new features in Java 1.5 and agree that yes, they are definitely a plus.(Note: I code nowadays almost exclusively in Java):

• No unsigned integer type in Java -- if you need an unsigned long, you're SOL. So it's pretty difficult to code certain numerical algorithms (compression and encryption, anyone?)
  
• Java the language is inextricably tied to the JVM - C# is just another option for developing for .NET.
  

For enterprise-grade work I still prefer J2EE over .NET, but that really more depends on what client I'm working for at the time. At the end of the day, both get the job done.

Re:Plenty of differences

[Deadbolt]

Behold BigInteger and its evil twin, BigDecimal. They laugh at silly-big numbers.

Re:Plenty of differences

[slyckshoes]

"Java the language is inextricably tied to the JVM - C# is just another option for developing for .NET."

Personally, I'd rather be tied to a JVM than an OS. There are JVMs for AIX, Linux, Windows, Mac, HP-UX, and others. Last I checked Windows was only available for IA32/64. Sure there's mono, but that's not yet a realistic option for enterprise development.

Re:APIs

[EmperorKagato]

The former has been in Java since 1.3, and the later since 1.1(!). Honestly, Java has every feature and the kitchen sink in its core APIs. And if a feature isn't there, it's very easy to write a library to add it. That's why programmers like Java so much

Wow. That sounds very familiar. And to think people wonder why there is a large fanbase for linux.

Welcome stranger!

[Oestergaard]

Welcome to planet earth - we also have a language called 'C++', but it is rather different from what you describe.

Here, we have compilers that can do bounds checking - avoiding buffer overflows, if you decide to use them.

However, the template feature of our C++ is so powerful, that when used together with structs and classes, one can produce beautiful code that is extremely powerful, yet so simple that it is easy to ensure it is not susceptible to said buffer overflows (or memory leaks or the thousand other plagues of much of the software that surrounds us).

This is why there is actually not anything fundamentally wrong with our C++. We are some who want template namespaces though, but outside of little issues (that do have workarounds) like that, the only things we really want is additions to the (already powerful) standard library, the STL.

One problem remains with our C++ though. We live on a planet inhabited mainly by clueless morons, people who do not like to learn, people who refuse to accept that maybe others have seen farther than themselves. This is why we, too, have a lot of problems with software in general - buffer overflows as you mention, among many other problems.

I am sure we can arrange for you to get a copy of our C++ standard - that will allow a clever individual, such as yourself, to write software without the problems we discussed. I would then suggest that we join our efforts, in teaching the unwashed masses how to actually use the language properly, so that we will not have to re-do all software in the world (both ours and yours) by ourselves.

Deal?

Re:Welcome stranger!

[archeopterix]

This is why there is actually not anything fundamentally wrong with our C++.

Except that you can actually program a GPF in C++. I call this fundamentally wrong.

More Features != Better Language

[Anonymous Coward]

Just because C# has more features does NOT make it a better language. Infact most of these Java 1.5 java changes annoy me. You could almost all these things in 1.4 there was just a certain way of doing it. If you have every programmed in C++ before with lots of different people who program things differently you will know that having different ways of doing things can be a VERY bad thing. This is way Java was so strong because there was 1 right way and 1 wrong way. Where in C++ you have like 3 right ways (that don't mesh together) and about 15 wrong ways to do something. Java is simpiler and faster to write code because you don't have 5 or 6 different ways of doing the same thing!

C# and Java are so similar....

[Manitcor]

that I dont care which a client wants anymore. Its like asking for 6 of one and a half dozen of the other. I had been afriad of learning Java for ages but knew C# very well. Then I forced myself to learn Java and as soon as I got into it I kept saying "Wow MS copied Sun!"

When you think about it though good OO concepts tend to evlove toward similar goals. Languane and usablitly concepts are the same all around. Its to the point now where the differences between Java and C# are more syntax and available libararies. Ive even been able to easily port Java to C# and vice versa since the languges are so similar.

It has defintaly opened up things more for me, as now I leave it to the client as to what they want. If they are an MS shop then C# is an obvious choice if they use Linux or perfer alternative platforms then Java is obviously what you should build in.

Re:APIs

[jchoyt]

I sincerely apologize for feeding troll. :oD

How exactly is Java "OO from the ground up"?

[argent]

Java's primitive types are not objects. There's no reason they couldn't have been (compilers that generated efficient arithmetic code from high level components date back to the '70s) but they're not... which means you have to drop down to C-style types over and over again.

It hinders programming efficiency, and it hinders code efficiency: any place where primitive types can be used, the compiler can infer that primitive code can be generated, any place it can't you'd have had to use object types... but the compiler is MUCH smarter about figuring where casts need to be than average (or even above-average) programmers.

Smalltalk is "OO from the ground up". Java is "OO from the Integer up".

Re:Only Microsoft

[mcc]

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.

Quick summary of the comments

[raider_red]

I haven't paged through the comments yet, but I'll bet I can tell what will be posted:

1. Java Sucks
2. C# sucks more, and it's put out by microsoft, which is evil.
3. Java's not so bad
4. C# is better than Java
5. Perl is better than either of them
6. Python rules!
7. "But I prefer [C/C++, Lisp, Fortran, Forth, etc.]"
8. In Soviet Russia...
9. I for one welcome our new [java|c#] overlords

And of course, this post will be modded as flamebait.

What about competition?

[dpw2atox]

Well people are here now saying oh java is better and people are saying that c# is better. In my opinion both are good and just like competition should do (assuming MS plays by the rules this time) both products will end up the better because of it. For the longest time java had no real competition (in my opinion) and its development slowed down greatly but now that C# is starting to be used more and more often javas development has finally started to take off again. Nothing but good can come from this so rather than flame each other over this I think we should simply consider what features might improve either language and attempt to talk to communicate with the developers when possible to request these features and improve competition all around.

The java generics system is a joke

[mrright]

The java generics system just saves typing and ensures type-safety for collections. But it does nothing about the problem of excessive boxing and unboxing that plagued java collection classes from 1.0 on.

For example if you have an ArrayList<Integer> in java, it internally uses an object[] to store the elements of the array. So everytime you write a new value to the ArrayList<Integer> by e.g. calling list.Add(i), a new object is allocated on the heap.

A List<int> in C# on the other hand uses an int[] internally, so adding or changing an element in the List<int> will result in no boxing/unboxing at all. A List will be just as fast as an int[] since the indexer method will be inlined.

The performance difference is dramatic: try creating an ArrayList<Integer>/List<int> and filling it with 1000000 numbers. The C# code will run 10 to 20 times faster, while the java version will use 20 bytes per Integer instead of 4 bytes per Integer like the C# version.

I am currently not at home, but if somebody is interested I will post a benchmark later.

Re:Java checked exceptions suck, but how to fix th

[rewt66]

Yeah, there's a syntax for this. It's called "put the try and catch in the function, with an empty catch block, and a comment that indicates why the exception can't happen." Then your function doesn't have to be declared as throwing an exception, and someone who looks at your code will understand that you didn't just eat the exception for no reason.

And, before you whine about having to write the try/catch block, let me echo what somebody else said, that an IDE like IntelliJ will do it all for you (except for the comment).

Re:varargs

[sbrown123]

Autoboxing/unboxing *shrug* nice when you need it, but how often do you actually need it?

I love this feature. Currently I have to do this sort of crap all the time:

String to int:

new Integer("1").intValue();

or parseInt

int to String:

String.valueOf(1);

In truth, Java should have dropped the primitive types altogether and went with a 100% object approach and allow things like this:

Integer _integer = 3;
Long _long = 5;
Number _number = _integer + _long;
_number--;

The above would be total sweetness.

What they should have done in 1.5 is strip out all the deprecated crap

Agreed. First to go: java.util.Date. And fix Calendar to be actually usefull.

pine? mutt

[flok]

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

You must have meant, of course mutt.

Rules on languages...

[feloneous cat]

I have a couple of rules when regarding languages:

1. Does it have wide industry support or is it merely another "we ship it until we kill it" single-sourced language.

2. Does the name sound like it could hurt you?

C# pretty much fills the bill (no pun intended) for both 1 and 2.

MS is no stranger to introducing something and then killing it some time later (hence my avoidance of both .NET and C#). And just when you get used to version XYZ, they come out with XYZ+1 which changes EVERYTHING. Sorry, I don't need my code to die at the whims of MS.

Then there is the whole "C#" name which, frankly, I think sounds retarded. To most Americans, the '#' symbol is pronounced "pound". Few people I know call it a "sharp" (actually, NO ONE that I know calls it that).

Finally, just the sound of it sounds dangerous and, if inserted in the wrong place (like my MIND) could cause harm.

It's the installation stupid

[nzgeek]

I've done enterprise-level Java and C# implementations for financial institutions, and reckon there is one thing that people always miss when comparing the two languages: installation.

C#, despite any other flaws, Just Works(tm). Install Visual Studio, write some code, click the run button. Sure it takes a bit of thinking to get a n-tier implementation up and running properly, but the installation of the back-end stuff (IIS, db connections, remoting) is incredibly simple.

On the other hand, to get enterprise Java (J2EE, although some would argue that a class library is easier and more versatile), you need to learn how to install an app server (JBoss, Orion, or god forbid WebSphere), and how to configure that system for database connections, performance, session and object permanence, etc..

None of this really matters in a 'big-iron' enterprise environment, because there's room to hire a websphere monkey to look after the cat-herding. In anything below a mega-corp or mega-bank however, the overhead of running Java can sometimes be a burden that developers just don't want to think about.

I see it kinda like using Firefox over IE. They both do pretty much the same thing, and one does it 'better', but at the same time requires some effort to implement. Some people just can't be bothered with the effort.

You're going to name it what?!

[richever]

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

Re:You're going to name it what?!

[p2sam]

I would had prefer Java 2000 over Java 2. The first one is clearly meant to be used for marketing purposes ( I think you Sun guys call it branding ). The later is ambiguous. I can't tell if it's a marketing name or an engineering version name.

With Java, stuck in Windows/Linux/Solaris

[RdsArts]

"I want C# on my *N*X/Window box"

http://www.go-mono.com/

"I want Windows.Forms support on my Mac/*N*X/Windows box"

http://www.dotgnu.org

If it's a choice of language based solely on the portablity of code, C# wins out IMHO. With Java, you're dependant on Sun to support your system, which is a royal pain. (as anyone with a *BSD box will tell you)

Re:With Java, stuck in Windows/Linux/Solaris

[shaper]

If it's a choice of language based solely on the portablity of code, C# wins out IMHO. With Java, you're dependant on Sun to support your system, which is a royal pain. (as anyone with a *BSD box will tell you)

I run a J2EE application on WebSphere on a mainframe under OS/390. Where's .Net for OS/390? I can (and have) also deploy that same application with zero changes to Linux, Windows, Solaris, AS/400 or Mac OS X. I can choose from a number of J2EE implementations like WebSphere, WebLogic, JBoss or Resin, each of which have different features and strengths. I don't even recompile, I just drop in the WAR and go.

And it is incorrect to say that you are dependent on Sun to support your system. Independent vendors like IBM, BEA and Apple also license and support J2SE and J2EE for their own platforms. My personal systems are Macs and I get my Java from Apple, not Sun. My corporate systems are IBM and I get my corporate Java from IBM, not Sun. If I have a problem with either, I don't call Sun, I call Apple or IBM. IBM provides my production support contract. IBM are the ones who responded with a custom patched version of WebSphere for OS/390 in less than 24 hours when I had a production problem. Not Sun.

Re:and how is this insightful?

[spacecowboy420]

Basically because he makes the point Java is portable and c# is not - no matter what the niceties of c# are, it misses this basic feature. Java is comparable to, if not exceeding the features of c#, in addition to its portability. We can readdress this when mono is finished and both languages are on a level playing field, until then, it's a moot point, Java rules. If MS supported .NET on other platforms, this would be a different discussion and not so cut and dry.

Re:Where can I get C#?

[ChatHuant]

Free C# compilator? Right here: .NET Framework SDK

Or here: Mono project

Free IDE? Here: Sharp Develop

Or, if you want to test .NET 2.0, go here:
.NET Framework 2.0 SDK

As you see, you don't have to pay anything to try C#; since you say you're convinced, go for it!

Apples and Oranges

[deuterium]

As other posters have said, I don't think that C# is meant for big enterprise apps, but littler 'toy' apps. Still, you'd be surprised how many of such apps are in use right now. The biggest strengths of C# are:

1)Simplicity. Everyone loves to argue about how purists should code things, but in the real world, a lot of code is written by people who are blissfully ignorant of theory. VS allows them to make obvious progress, reusability be damned. A crude, but working app is more impressive to a clueless manager than a collection of nascent classes.
2)Integration. This goes along with #1. Much of the heavy lifting in creating desktop apps is rolled into .NET, so that a user can program to a higher level library. Documentation is all there. It also provides all of the tools and files needed in one tidy install, without the need for combining different packages. It all comes from one vendor, and it's easy to get your mind around.
3)ASP.NET. I would argue that ASP.NET is the easiest way to accomplish application-like behavior in a web site. Session state works well, database access is a couple lines of code, and you can even draw the page on a coordinate system if HTML stymies you. Scorn it if you must, but it's a good step toward standardizing web/application development.

varargs is *not* an enhancement

[hopethishelps]

5. Varargs (C# 1.0's params construct, ellipsis construct in C++)

As Stroustrup says of the ellipsis construct in C++, "The most common use of the ellipsis is to specify an interface to C library functions that were defined before C++ provided alternatives", and gives an example of the "extra work that face[s] the programmer once type checking has been suppressed using the ellipsis." Using the ellipsis construct, other than where it has to be used to access some legacy C library, is definitely very poor style in C++.

The libraries will make/break a language

[chiph]

The included libraries will make/break a language, and right now, the .NET libraries are much easier to use. Partly because they were designed "as a whole" and don't have a lot of cruft in them (yet). And partly because the MS on-line help is vastly superior to JDoc (does Sun not believe in code samples?).

The biggest weakness I see in the .NET framework is that 90% of it uses concrete implementations. Because they didn't use an Interface-driven design, they now have to fall back on the Win32 style of appending "-ex" to class names when they want to improve them, rather than letting a dynamic loader find the class the developer needs.

Even so, the Visual Studio IDE is so far ahead of any of the Java IDEs (Eclipse comes closest), that it's probably Microsoft's single best competitive advantage.

Chip H.

Java:JVM != .NET:C#

[DoubleReed]

C# is just one option for .NET eh?
Hmm... if only there were some other languages that could be compiled to JVM bytecode.

C#2.0 and IDEs

[shodson]

DISCLAIMER: I develop heavily in both C# and Java, more C# than Java, about 80% C#, 20% Java, not by choice but based on client demands.

I don't think it's fair to compare Java 1.5 (released) vs. C# 2.0 (beta, who knows when it'll actually be released). That's like comparing Linux to Longhorn.

And re: IDEs, while programming so much in VS.NET, I missed all of the cool features of my IDEA IntelliJ Java IDE that I was excited to buy ReSharper, bringing some of IDEA's cool features to VS.NET.

One of the main things I like about .NET, though, is that the libraries seem to be more consistent, whereas the Java APIs have evloved and been added to by different developers using diffferent programming styles and approaches to patterns, each package seems to implement different programming styles and constructs, but you get used to it after a while. Plus, Java has so much deprecated code, they need to clean those out once and for all and clean up the APIs, see this for more details of what I'm talking about.

Operator overloading

[evilpenguin]

Say Amen!

Just because operator overloading can be used for evil is no reason to throw the baby out with the bathwater.

Java lacks a Currency class, so I wrote a Money class some time ago that I use for common financial calculations, and it takes care of the pesky problem (and newbie mistake) of using floating point types for money.

BUT, in Java, you have to have add(), sub(), mult(), and div() methods. Reading RPN style caclulations consisting of sequenced and nested method calls instead of algebraic operators is painful. Operator overloading is wonderful in those cases.

Operator overloading certainly can be evil: What does it mean to increment an Employee? Do I really want to know? But for new types that you can actually do algebra with, it is quite helpful.

And there are other cases.

In my C++ days I wrote a FileHash class that kept an index of offsets to the start of each text line in a text file. Then I overloaded the array subscript operator so that a text file could used like an array of char pointers (or a String class if you liked). That was a perfectly good use of overloading.

Moreover I think overloading the array subscript on ordered collections also makes perfect sense.

I often wish Java had this feature. I agree with every simplifying choice they made except this one.

Re:and how is this insightful?

[angel'o'sphere]

Yeah,

indeed, debuggin in visual studio is awesome. Granted. Hm, does anyone remember the company from wich MS bought that technology? I can reboot one of my very old 486 (year 1993) PCs where I have used the same debugger on Symantec C++ 6.0 (Larry Wall, D++, ever heared about?). Frankyl, I don't see much improvement in Visual Studio, but my latest version is from 1999 ... in respect to Symantec C++.

OTOH, I use Eclipse at my customer sides .... because they never heared about IDEA IntelliJ or about Omnicore CodeGuide :D at home I use CodeGuide for dayly work and Eclipse for CVS.

I would dare a statement:
*ALL* Java IDEs are *FAR* beyond any C++/Microsoft IDE. The only thing comming close to Eclipse is SNIFF+ from WindRiver (shit, forgot the old company name, was it Take Five?) ... well, the old SNIFF IDE was crafted by the same guy behind Eclipse. But thats a guy from GOF ... and most /.ers put OO and patterns into one basket and still think assembler rules :D

angel'o'sphere

Re:and how is this insightful?

[ckaminski]

I'm not too found of Intellisense, actually. I've found that 99% of the time, it locks up my interface while it searches the browser database for a tag, and or it requires me to move my hands from the alpha keys to the arrows to complete a task. It's mentally exhausting to deal with when all I want to do is stream-of-consciousness programming.

I won't even deal with auto-format which is much worse in my opinion...

But to each his own. Best of luck to you!

-Chris
----
Visual C++ user since 2.0.

Bias article?

[AstroDrabb]

I use both Java and C# professionally and this post smells of bias.

in my NSHO, the Java API has become bloated...

Huh? The Java 5 JRE download is 14 MB, while the .Net 1.1 runtime is 24MB. The Java 5 SDK download is 44MB while the .Net 1.1 SDK download is a whopping 109MB! Which one has bloat again? Java by far beats out C#/.Net as far as 3rd party modules goes. Anything you can think of programming, there is something available in Java. I cannot say the same yet about C#/.Net.

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

Does this guy know _anything_ about the Java community? The fortune 500 where I work had a few meetings trying to figure out which vendor we would use for our JAVA IDE. There was no choice with our C# IDE, it was just MS. For Java, we looked at IBM, Sun, BEA, JCreator, Eclipse, IntelliJ and Borland. If SUN died, we would still have _PLENTY_ of choice.

I like both Java and C# from a language perspective, however, working for a large company, I would recommend Java over MS's .Net. Java has been _very_ stable and _SECURE_ while the .Net security holes have already started at only version 1.1. We also appreciated the fact that we were able to switch our Java server apps to Linux over Solaris, we could even use MS Windows if we wanted to for our Java app servers; we don't have that same choice or luxury with MS .Net.

Exceptions...

[r6144]

In C++ the decision whether or not to make use of exceptions is hard to make. If you don't use exceptions, the results of many function calls have to be checks, which is considerably more of a hassle than Java. If exceptions are used, writing exception-safe code is really quite limiting (It often means significantly more little objects when "new" can't be used freely, and much of the existing code have to be rewritten, and I hate comments like "func() can't throw, so this is safe"). Seems that an garbage-collecting language like Java/C# is very helpful if one want to use exceptions.

Re:Java is a 32-bit language; C# is a 64-bit langu

[kaffiene]

Pure and utter FUD

from http://www.manageability.org/blog/stuff/why-cant-m icrosoft-deliver-64-bin-dotnet/view

Despite having a research and development budget that is almost 7 billion dollars a year, Microsoft apparently can't deliver .NET for 64-bit Windows 2003. Infoworld in a recent analysis explains:

The lack of a 64-bit implementation of the .Net Framework means that the hard work many Windows developers have put into migrating to the .Net development model is for naught on Windows on Itanium.
In the meantime, IT shops that wish to employ 64-bit Windows as an application server or Web services platform will be forced to revert to the older, Windows DNA (Distributed Internet Applications) environment.

In stark contrast, BEA Systems and Sun have been shipping JRockit and J2SE with Itanium support ever since JDK 1.4.1 was released. Furthermore, according to the reports 64-bit Opteron support is expected at the same time JDK 1.5 is released.

Re:Only Microsoft

[mcc]

Well, that is an API issue, not a language issue.

If you wish to address it as an issue with the Java API, the problem there is that it ignores the question of: if exceptions could be just ignored, what other changes to the Java API would be necessary in order to accommodate this? The API designers could no longer assume exceptions thrown by API methods would be caught. This would certainly have a serious impact on how the APIs are constructed and interfaced with.

Any place for both of them ?

[dweeves]

It's too easy to give C# an advantage about what it adds to Java and forgetting it's a 95% Java clone.

Don't forget It took 7 years of Java and a Borland expert to produce C# !

During this time, Java did conquer most of the enterprise application development market and defined a technology model based on application servers handling component lifecycles.

C# as a language,has taken most of java state of the art paradigms and added some new features which are neat but, despite its huge base library is far from Java versatility and degree of maturity.

Java 1.5 advantages

• Language Features/Libraries:

• Server side Programming:
• Defined server side technology paradigms, with lots of implementors to handle them (open source and free ones are competing with the best commercial ones).

• Client Side Programming:
• Applets (which aren't dead technology if you know how to use them)
• Web Start

• IDE/Tools
• Eclipse (which is free and open)

• Management aspects
• Lots of available skilled developers
• Can run on any platform with a compliant JVM (if well coded)
• All big database vendors have JDBC drivers
• Mature technology

Java 1.5 Drawbacks

• Server Side:
• Web Service support are expensive to implement and non-standardized.
• Very poor JSF controls

• Client Side:
• Swing (but SWT / Eclipse rocks)

C# advantages

• Language Features:
• Benefits from the .Net Jitter.
• Events/Delegates model

• Client Side:
• Future Windows Development preferred language (along with XAML which is more about powerful UI macro-scripting)
• DirectX integration
• Speed (on Windows)

• Server Side
• ASP.Net Controls model

• IDE/Tools
• VS .Net (most productivity boosting IDE IMHO)

• Management aspects
• Still time to have plenty of Microsoft support if you have a interesting project.

C# drawbacks

• Language Features
• No Observable/Observer (but achievable through Events/Delegates)
• Serialization limitations

• Client Side
• No Windows independent GUI framework. (WebForms are server-based controls)
• No applets equivalent (don't event think about ActiveX)

• Server Side
• No detailed Infrastructural model, No best practices, No fine grained control.

• IDE/Tools
• No free IDEs compares to VS .Net and is really useable when you're used to commercial IDEs features. (Borland C# Builder CE is too restricted and not open source)

• Management aspects
• Young technology
• Not that much real experts available out of Microsoft
• Windows deployment only (Mono's out, but still work in progress ,can't be a professional choosen .NET deployment platform yet IMHO)

So, my conclusion is that by now, both technologies are interesting but Java is the most versatile.

I would prefer C# for:Windows Programming ,Attractive Web based interfaces (if an acceptable target platform is Mono or Windows), Porting existing windows applications to Web, Simple Self-Contained Web Services

I Would prefer Java for developing:Enterprise Applications,Complex Web Services,Highly interactive web interfaces (through applets),Multi OS client application.

For me, both languages are relevant, it's only a matter of what work has to be done and what resources are available to make it.Most of the time, technology is chosen based on a company resources capabilities!

Re:and how is this insightful?

[generalpf]

You press CTRL-Break. It's undocumented but it works, even when you're surrogate-debugging a COM object.