5 ms·

Java and C# "Comparison"

27 points by Garbage 16y ago

jasonkester 16y ago
It seems a bit silly to compare syntax of these two languages, when the thing that makes them what they are is their class libraries. So as you can see, they're nearly identical in syntax. But that doesn't mean they're even similar in terms of being suitable for a given task. I'd like to see a comparison of Java's standard class libraries as compared to .NET. How do you open a file in each? Execute a stored procedure and spin thru the returned recordset. That's where the interesting stuff lies, and where the ecosystems diverge.
sukuriant 16y ago
My first thought was that this will be a very incomplete list. I was right. Where is the delegate vs anonymous class comparison. What about the horrible tricks you can do to emulate refs (pass an array with the reference in it, instead), and the less horrible thing you can do with out parameters (create a return class)? What about the differences in the implementation of proper event-driven design between the two languages? And the biggest difference I've experienced between the two, what about the general design and thought behind their different standard APIs? All in all, I was very underwhelmed. This should have fleshed the real differences (to me the thought behind their APIs) out. [edit: finally reading the small text underneath the title, I see this is a syntax comparison. A couple of my statements still make sense, but this really needs to have its title changed. I suppose people wouldn't read it if that were the case, though.]
- henrikschroder 16y ago
  Worse, it's a syntax comparison from Java to C#, i.e. a "how do I" for Java people writing C#, not the other way around. For example I saw it list the ?: operator, but where is the ?? operator that C# has and Java sorely lacks? Where's the using block? Delegates? LAMBDA EXPRESSIONS?!?
wladimir 16y ago
I almost didn't click because I feared this was a language war post, but this is actually a pretty useful comparison sheet showing the language syntaxes.
seanlinmt 16y ago
Here's a more exhaustive comparison of Java and C#. http://www.25hoursaday.com/CsharpVsJava.html http://www.25hoursaday.com/CsharpVsJava.html
- sukuriant 16y ago
  This is more like what I was hoping for and even mentioned things I'd forgotten in my list
fleitz 16y ago
There are some problems with it. Java: import harding.compsci.graphics.Rectangle; // Import single class C#: // Import all class. Can't import single class. Correct answer: using Rectangle = Harding.CompSci.Graphics.Rectangle; // import single class
- Groxx 16y ago
  I've been using this trick to get around the uber-global-scope that exists where I'm working. Two versions of utility tools exist with identical scopes and names (don't ask why), so re-naming the class with "using" is the only way to force the selection. I wish I'd seen this comment a couple months ago when I was trying to figure out wtf was going on.
  - S_A_P 16y ago
    maybe Im misunderstanding you here, but when you have a collision of namespaces like that cant you just fully qualify the object you want? eg var foo = new Name.Space.Object(); For me the using statement in C# is handy shorthand for something that implements IDisposable(say, SqlClient for example) making sure that Dispose gets called.
    - sukuriant 16y ago
      The using statement the flietz is referring to goes at the beginning of the program, generally, next to all of the other "usings". It's mostly useful when you don't want to type out the fully qualified name of a class just to use an object of it. It's a code brevity feature.
    - Groxx 16y ago
      No, though say you have three nested namespaces for your utility class, and many other classes in those namespaces at varying levels and another version by the same name exists in global scope. There's even another version of the same class that's deprecated, but used in one or two places, and sites mid-way through the namespacing. And ASP is so #^@%in brilliant, everything resides in a single app_code folder and non-namespaced classes cannot be not-imported (as far as I've been able to tell). You can name.space.the.object, absolutely. Though it's closer to TheMasterNameSpace.Utilities.DatabaseConnectivity.TheClassNameThatIsUnnecessarilyLong, and that would have to be typed every time you wish it to be used. That amounts to literally hundreds of times that must be typed in some of the larger chunks of code, and tens of thousands if not significantly more over the course of a decent sized project. Changing this to "using TC = ..." makes it immensely less of a PITA, and changing it to use a different version (with the same API) requires changing a single location. And I am fully, painfully, daily aware of how bad this architecture is, there's no need to point this out. I'm part of the process of correcting this injustice.
nigelsampson 16y ago
It seems to be a very old comparison, missing generics from both and lots of other features, been a long time since I've done any Java but it seems like its C# 1.0 compared to Java 6?
- Stormbringer 16y ago
  The generics are on the Java side at least once. See the ArrayList<Object> example. Personally, if I was going to use a generic list based on <Object>, I'd just use ArrayList or Vector without the generic notation. And then if the compiler issued a warning I would bitch slap it and tell it to go make me some money. I laugh because part of the argument for generics was that they would make code shorter and easier to read. Yet they make the code harder to read, and I seemed to write much less code when all I had to do was cast the object when I took it out of the collection. Anyway, there are some instances where generics are useful, things like HashMaps. The problem is, the people who write crappy HashMap code invariably are abusing it to try to avoid writing a proper object. E.g. they're using it as a list of named properties or attributes, some of which may or may not be there this time round. If they'd just shove it into an object, it would make things a lot easier to read. The only downside is they would have to put checks for null all over the place. Since this would actually make their code more robust, make them a better programmer and also make them a better person in general, I have no problem with that 'drawback'.
  - whateverer 16y ago
    You didn't just tell us all that being forced to check for null references strengthens the spirit, now did you? That is akin to saying that being forced to check for buffer overflows is edifying, or that no programmer from a good family uses garbage collectors.
    - Stormbringer 16y ago
      No it's not. Checking for nulls (and it's brother-by-a-different-mother catching exceptions) is entirely in keeping with the philosophy of being lenient in what you accept as input. Checking for nulls is good practice because it makes you think about what is happening in the code. It makes you think about making design decisions about how you will handle nulls. It makes you aware that some libraries out there may return null from a method call. It makes you aware that no matter how often you make your co-workers sign a death pact in their own blood that they will never return a null or pass you a null, that they may do so anyway either through omission or commission (incompetence or miscomprehension or some weird boundary condition). Checking for nulls is compatible with a philosophy of thoroughly testing your code. Even if you are the perfect programmer, others are not. Refusing to check for nulls is to be at risk of disagreeing with reality how it should work. Reality always wins. Realising that if everyone else is not perfect, that perhaps they are also not perfect, is what causes the personal growth benefit I ascribed to being a more careful programmer.
fletchowns 16y ago
I thought this page was supposed to be a joke just to illustrate how similar they can be.
InclinedPlane 16y ago
A more accurate description: a translation of C# 1.0ish syntax for Java code examples. Java and C# are no longer directly comparable in my opinion, the introduction of first class functions, extension methods, and LINQ in general make modern C# a far more expressive language than Java is currently capable of (notwithstanding several extremely expressive JVM based languages such as scala and clojure).
- Stormbringer 16y ago
  You appear to be confusing having more features with being more powerful. An easy mistake to make, but not necessarily true.
  - jamesrom 16y ago
    Not once in his comment did he say anything even close to 'being more powerful'. Why did you interpret it that way? You appear to be confusing a well made point with something that was never said.
    - SeanLuke 16y ago
      Let us try again. He is confusing having more features with being "more expressive" (whatever that means). And even if we work out what that means, he's confusing "being more expressive" with "being more powerful" (whatever THAT means). By this logic, C++ is the language to beat.
      - viraptor 16y ago
        Expressiveness usually means "working code to boilerplate ratio". For example: (C#) SomeMethod((x) => SomeOtherMethod(x)); is more expressive than: (java) class WrapperIDontReallyNeed() { public void AnotherWrapper(uselessType x) { SomeOtherMethod(x); } } ... SomeMethod(new WrapperIDontReallyNeed()); (or anonymous classes - before someone points out they exist - just trading Wrapper for IWrapper and no `class` keyword) And again - I don't see any mention from his side about being powerful. I don't think he's confusing anything either - expressiveness of a language is a pretty common term and is true in this case. C++ is easy to beat from that point of view, unless you add a tonne of Boost.
Stormbringer 16y ago
There were some problems I noted: first example, the package statement is redundant. That would make the java example much shorter, and apparently shorter code is inversely proportional to e-peen length or something like that. XML comments sounds like an interesting feature, but isn't the real feature that C# treats XML as a native type (or something like that??) decimal as a type sounds interesting, does that let you do high precision financial math and/or math for large amounts of dollars? object: C# capitalisation looks really random to me. I worked on a Java project once with a guy who learned on something that was almost, but not quite proper Java (Jada?) and reading his code was an exercise in going wtf? Because he didn't follow (or know, or understand) the first letter capitalisation rules. For pi, you should of course use Math.PI not 3.14 I think the enum syntax is wrong in Java, don't you need to spray angle brackets all over it in a mad orgy of generically making it much harder to read? Also, I don't think his println will do what he says it will do as he hasn't defined a toString method??? Or is the enum magical enough to figure that out on its own? I knew his capitalisations were buggered up, Math.Pow does nothing in Java, should be Math.pow Converting an int to a string should be: String s = "" + x; Converting the string back into an int should be longer, you need to catch the possible conversion exception NumberformatException If you're converting doubles to whole numbers, you should probably put them into either a long or a BigDecimal, rather than an int. For string concatenation I think he's missed += I know a lot of people don't like it because they think it is slow or bad form, but the smart guys at Sun optimised the buggery out of it, so it goes like a greased rattlesnake. Check the bytecode that is produced if you don't believe me. From the article: throw up; I just about did. Sorry, I had to stop, I couldn't continue. import pounding.headache;
- viraptor 16y ago
  First package was for a comparison only. C#'s 'namespace Hello' wasn't necessary either. XML comments are more of a convention. Compiler won't prevent you from makin incorrect xml there. Yes, that's what decimal is for. Capitalisation is pretty simpl(e/istic) http://msdn.microsoft.com/en-us/library/ms229043.aspx http://msdn.microsoft.com/en-us/library/ms229043.aspx Enums -> yes, they's that magical: http://download.oracle.com/javase/1.5.0/docs/guide/language/enums.html http://download.oracle.com/javase/1.5.0/docs/guide/language/...

27 points by Garbage 16y ago

It seems a bit silly to compare syntax of these two languages, when the thing that makes them what they are is their class libraries. So as you can see, they're nearly identical in syntax. But that doesn't mean they're even similar in terms of being suitable for a given task. I'd like to see a comparison of Java's standard class libraries as compared to .NET. How do you open a file in each? Execute a stored procedure and spin thru the returned recordset. That's where the interesting stuff lies, and where the ecosystems diverge.

sukuriant 16y ago

My first thought was that this will be a very incomplete list. I was right. Where is the delegate vs anonymous class comparison. What about the horrible tricks you can do to emulate refs (pass an array with the reference in it, instead), and the less horrible thing you can do with out parameters (create a return class)? What about the differences in the implementation of proper event-driven design between the two languages? And the biggest difference I've experienced between the two, what about the general design and thought behind their different standard APIs? All in all, I was very underwhelmed. This should have fleshed the real differences (to me the thought behind their APIs) out. [edit: finally reading the small text underneath the title, I see this is a syntax comparison. A couple of my statements still make sense, but this really needs to have its title changed. I suppose people wouldn't read it if that were the case, though.]

henrikschroder 16y ago
Worse, it's a syntax comparison from Java to C#, i.e. a "how do I" for Java people writing C#, not the other way around. For example I saw it list the ?: operator, but where is the ?? operator that C# has and Java sorely lacks? Where's the using block? Delegates? LAMBDA EXPRESSIONS?!?

wladimir 16y ago

I almost didn't click because I feared this was a language war post, but this is actually a pretty useful comparison sheet showing the language syntaxes.

seanlinmt 16y ago

Here's a more exhaustive comparison of Java and C#. http://www.25hoursaday.com/CsharpVsJava.html http://www.25hoursaday.com/CsharpVsJava.html

sukuriant 16y ago
This is more like what I was hoping for and even mentioned things I'd forgotten in my list

fleitz 16y ago

There are some problems with it. Java: import harding.compsci.graphics.Rectangle; // Import single class C#: // Import all class. Can't import single class. Correct answer: using Rectangle = Harding.CompSci.Graphics.Rectangle; // import single class

Groxx 16y ago
I've been using this trick to get around the uber-global-scope that exists where I'm working. Two versions of utility tools exist with identical scopes and names (don't ask why), so re-naming the class with "using" is the only way to force the selection. I wish I'd seen this comment a couple months ago when I was trying to figure out wtf was going on.
- S_A_P 16y ago
  maybe Im misunderstanding you here, but when you have a collision of namespaces like that cant you just fully qualify the object you want? eg var foo = new Name.Space.Object(); For me the using statement in C# is handy shorthand for something that implements IDisposable(say, SqlClient for example) making sure that Dispose gets called.
  - sukuriant 16y ago
    The using statement the flietz is referring to goes at the beginning of the program, generally, next to all of the other "usings". It's mostly useful when you don't want to type out the fully qualified name of a class just to use an object of it. It's a code brevity feature.
  - Groxx 16y ago
    No, though say you have three nested namespaces for your utility class, and many other classes in those namespaces at varying levels and another version by the same name exists in global scope. There's even another version of the same class that's deprecated, but used in one or two places, and sites mid-way through the namespacing. And ASP is so #^@%in brilliant, everything resides in a single app_code folder and non-namespaced classes cannot be not-imported (as far as I've been able to tell). You can name.space.the.object, absolutely. Though it's closer to TheMasterNameSpace.Utilities.DatabaseConnectivity.TheClassNameThatIsUnnecessarilyLong, and that would have to be typed every time you wish it to be used. That amounts to literally hundreds of times that must be typed in some of the larger chunks of code, and tens of thousands if not significantly more over the course of a decent sized project. Changing this to "using TC = ..." makes it immensely less of a PITA, and changing it to use a different version (with the same API) requires changing a single location. And I am fully, painfully, daily aware of how bad this architecture is, there's no need to point this out. I'm part of the process of correcting this injustice.

nigelsampson 16y ago

It seems to be a very old comparison, missing generics from both and lots of other features, been a long time since I've done any Java but it seems like its C# 1.0 compared to Java 6?

Stormbringer 16y ago
The generics are on the Java side at least once. See the ArrayList<Object> example. Personally, if I was going to use a generic list based on <Object>, I'd just use ArrayList or Vector without the generic notation. And then if the compiler issued a warning I would bitch slap it and tell it to go make me some money. I laugh because part of the argument for generics was that they would make code shorter and easier to read. Yet they make the code harder to read, and I seemed to write much less code when all I had to do was cast the object when I took it out of the collection. Anyway, there are some instances where generics are useful, things like HashMaps. The problem is, the people who write crappy HashMap code invariably are abusing it to try to avoid writing a proper object. E.g. they're using it as a list of named properties or attributes, some of which may or may not be there this time round. If they'd just shove it into an object, it would make things a lot easier to read. The only downside is they would have to put checks for null all over the place. Since this would actually make their code more robust, make them a better programmer and also make them a better person in general, I have no problem with that 'drawback'.
- whateverer 16y ago
  You didn't just tell us all that being forced to check for null references strengthens the spirit, now did you? That is akin to saying that being forced to check for buffer overflows is edifying, or that no programmer from a good family uses garbage collectors.
  - Stormbringer 16y ago
    No it's not. Checking for nulls (and it's brother-by-a-different-mother catching exceptions) is entirely in keeping with the philosophy of being lenient in what you accept as input. Checking for nulls is good practice because it makes you think about what is happening in the code. It makes you think about making design decisions about how you will handle nulls. It makes you aware that some libraries out there may return null from a method call. It makes you aware that no matter how often you make your co-workers sign a death pact in their own blood that they will never return a null or pass you a null, that they may do so anyway either through omission or commission (incompetence or miscomprehension or some weird boundary condition). Checking for nulls is compatible with a philosophy of thoroughly testing your code. Even if you are the perfect programmer, others are not. Refusing to check for nulls is to be at risk of disagreeing with reality how it should work. Reality always wins. Realising that if everyone else is not perfect, that perhaps they are also not perfect, is what causes the personal growth benefit I ascribed to being a more careful programmer.

fletchowns 16y ago

I thought this page was supposed to be a joke just to illustrate how similar they can be.

InclinedPlane 16y ago

A more accurate description: a translation of C# 1.0ish syntax for Java code examples. Java and C# are no longer directly comparable in my opinion, the introduction of first class functions, extension methods, and LINQ in general make modern C# a far more expressive language than Java is currently capable of (notwithstanding several extremely expressive JVM based languages such as scala and clojure).

Stormbringer 16y ago
You appear to be confusing having more features with being more powerful. An easy mistake to make, but not necessarily true.
- jamesrom 16y ago
  Not once in his comment did he say anything even close to 'being more powerful'. Why did you interpret it that way? You appear to be confusing a well made point with something that was never said.
  - SeanLuke 16y ago
    Let us try again. He is confusing having more features with being "more expressive" (whatever that means). And even if we work out what that means, he's confusing "being more expressive" with "being more powerful" (whatever THAT means). By this logic, C++ is the language to beat.
    - viraptor 16y ago
      Expressiveness usually means "working code to boilerplate ratio". For example: (C#) SomeMethod((x) => SomeOtherMethod(x)); is more expressive than: (java) class WrapperIDontReallyNeed() { public void AnotherWrapper(uselessType x) { SomeOtherMethod(x); } } ... SomeMethod(new WrapperIDontReallyNeed()); (or anonymous classes - before someone points out they exist - just trading Wrapper for IWrapper and no `class` keyword) And again - I don't see any mention from his side about being powerful. I don't think he's confusing anything either - expressiveness of a language is a pretty common term and is true in this case. C++ is easy to beat from that point of view, unless you add a tonne of Boost.

Stormbringer 16y ago

There were some problems I noted: first example, the package statement is redundant. That would make the java example much shorter, and apparently shorter code is inversely proportional to e-peen length or something like that. XML comments sounds like an interesting feature, but isn't the real feature that C# treats XML as a native type (or something like that??) decimal as a type sounds interesting, does that let you do high precision financial math and/or math for large amounts of dollars? object: C# capitalisation looks really random to me. I worked on a Java project once with a guy who learned on something that was almost, but not quite proper Java (Jada?) and reading his code was an exercise in going wtf? Because he didn't follow (or know, or understand) the first letter capitalisation rules. For pi, you should of course use Math.PI not 3.14 I think the enum syntax is wrong in Java, don't you need to spray angle brackets all over it in a mad orgy of generically making it much harder to read? Also, I don't think his println will do what he says it will do as he hasn't defined a toString method??? Or is the enum magical enough to figure that out on its own? I knew his capitalisations were buggered up, Math.Pow does nothing in Java, should be Math.pow Converting an int to a string should be: String s = "" + x; Converting the string back into an int should be longer, you need to catch the possible conversion exception NumberformatException If you're converting doubles to whole numbers, you should probably put them into either a long or a BigDecimal, rather than an int. For string concatenation I think he's missed += I know a lot of people don't like it because they think it is slow or bad form, but the smart guys at Sun optimised the buggery out of it, so it goes like a greased rattlesnake. Check the bytecode that is produced if you don't believe me. From the article: throw up; I just about did. Sorry, I had to stop, I couldn't continue. import pounding.headache;

viraptor 16y ago
First package was for a comparison only. C#'s 'namespace Hello' wasn't necessary either. XML comments are more of a convention. Compiler won't prevent you from makin incorrect xml there. Yes, that's what decimal is for. Capitalisation is pretty simpl(e/istic) http://msdn.microsoft.com/en-us/library/ms229043.aspx http://msdn.microsoft.com/en-us/library/ms229043.aspx Enums -> yes, they's that magical: http://download.oracle.com/javase/1.5.0/docs/guide/language/enums.html http://download.oracle.com/javase/1.5.0/docs/guide/language/...