Talk:Comparison of C Sharp and Java/Archive 2

Archive 1

Archive 2

Archive 3

Delegates, closures and events

I tidied up these sections as there was some glaring misconceptions (delegates, events, closures and observer pattern were all lumped together) and some NPOV issues ("plain, old object-oriented design"). —Preceding unsigned comment added by Useerup (talk • contribs) 04:54, 18 May 2010 (UTC)

Operator overloading

Any idea what was intended when someone wrote:

In Java Operator Overloading is performed by language itself only Like '+' Operator. (String + any other object = String) and (int + int = int). but this facilities can not provide to our application. ( By- Bhanu Pratap Singh )

Makes little sense to me - hardly operator overloading at all. Removing. Amniarix (talk) 19:43, 1 July 2009 (UTC)

Is this comparison an error?

In this article everybody is mixing up the runtime environment (JRE <-> .NET Framework) with language features. I think this is an error.Thomas Maierhofer (talk) 12:47, 20 January 2009 (UTC)

Well, the two languages are somewhat closely tied to their runtime environment. That said, for the most part anything related to the platforms has been factored out to Comparison of the Java and .NET platforms. – Chip Zero 23:10, 21 February 2009 (UTC)

Decimal types

Why does the data types chart say "No" for C# for "Big decimal (financial) type", and then provide a cite link to an article on the big decimal/financial data type "decimal" in the C# online reference? —Preceding unsigned comment added by Cerowyn (talk • contribs) 18:04, 8 February 2010 (UTC) Big Decimal is a particular type of Arbitrary-precision arithmetic, which is supported in Java, Ruby or Python, but not in C#, which "only" has a decimal type defined with 128 bits maximum. Hervegirod (talk) 21:43, 8 February 2010 (UTC)

Big decimal is not a rigorously defined term, and does not require arbitrary precision to my knowledge. Given that the row header indicates that it is for financial information, and the 128 bit C# data type can express any reasonable financial figure (leaving five decimal places, you could still express a number with a magnitude into the sextillion range), it clearly supports big decimal. No, it's not useful for some scientific and mathematical applications, but for financial data it's more than adequate. The full explanation is much more accurate; neither Java nor C# supports arbitrary precision arithmetic in the way a language like Python does, but both support it for specific problem sets. Reducing it to "yes" and "no" based on your personal interpretation of what Big Decimal means is disingenuous. —ShadowRanger ^(talk|stalk) 21:55, 8 February 2010 (UTC)

To my knowledge Java support arbitrary precision arithmetic, for integer and decimal values. The definition of the BigDecimal class for Java clearly states: "Immutable, arbitrary-precision signed decimal numbers". So for Java it's a clear yes IMHO. As for C#, only using 128 bits for the prevision makes it just a special new kind of decimal data, with no arbitrary precision (the way that java stored its values is very different from C#, because of the need for real arbitrary precision). I also don't know why it's just given for financial computations in the table, because arbitrary precision arithmetic also has a common use case in cryptography, something that C# can not do with its decimal data type. I wonder if who put this comment in the first place wanted to show C# at its advantage here.

I think that the C# decimal data type is an implementation of the Decimal128 floating-point format. In that sense, Java and C# both implement it, and it is true that for this particular format, C# has a built-in data type, and not Java (simply because this format is achieved in Java by BigDecimal with a specific math context for rounding. However, there is also an unlimited rounding for BigDecimal in Java, something that C# clearly does not support.

The table would be accurate if saying that Java and C# both implement Decimal128 floating-point format, but that only Java implement arbitrary precision arithmetic (I think that there is no BigInteger equivalent in C# too) Hervegirod (talk) 22:48, 8 February 2010 (UTC)

For Java it's in a weird nebulous state. Saying "the language supports something", when what you really mean is "a library for the language supports something" is slightly inaccurate. Java's language spec doesn't include the BigDecimal class, even though it ships with the default distribution. I've split the row into two, you tell me if you think it's acceptable. —ShadowRanger ^(talk|stalk) 17:45, 9 February 2010 (UTC)

BTW, while I'm aware that the Java char type is technically, unsigned, it's a little odd to list it as a usable unsigned data type. Mostly because I'm terrified of hyper-optimizing C programmers trying to use it as such. No rational programmer would try to swing unsigned math using a char in Java, and no Java manual would suggest it. Does anyone object to switching this to a plain No? —ShadowRanger ^(talk|stalk) 17:55, 9 February 2010 (UTC)

Hello, sorry for being late ;) I would trade "First Party Library" by "Java Class Library". And why getting rid of the char type in Java. AFAIK, it's exactly the same 16 bits data type as in C, or C#. But that it's unsigned is important IMO, because it unsigned 16 bits encoding is very useful for Unicode representations for example. Hervegirod (talk) 00:38, 12 February 2010 (UTC)

I have updated the decimal128 row and arbitrary size floating point rows to reflect the fact that 1) Java does not have a native decimal128 type but does have an *arbitrary* precision floating point as non-1st class library type. C# with basic library now comes with complex numbers and arbitrary size integers, but *not* arbitrary size floating point. —Preceding unsigned comment added by 152.73.73.1 (talk) 13:20, 17 May 2010 (UTC)

Generator methods

I have started incorporating the "notations and special features" into the main body of the text while trying to preserve the examples. I started with "yield" and generator methods. This statement: "in C#, both the generic and non-generic versions must be implemented at the same time, adding length to the code" is false. I have removed it. If anyone can come up with a reference to such a requirement, please cite. Useerup (talk) 08:20, 9 June 2010 (UTC) I also removed the reference to "Project Lombok". Lombok is 1) not a language, VM or library feature, 2) not from a 1st party (Sun/Oracle), 3) relying on brittle byte-code manipulation which is not compatible with all VMs and have known incompatibilities with IDEs. It does not belong here. Useerup (talk) 09:05, 9 June 2010 (UTC)

The OS chart ignores Mono

The Operating Systems chart gives C# a "no" for Mac OS/X and the assorted flavors of Linux, and yet we have the Mono project mentioned just a few lines above. Did the author of the article forget to read Wikipedia's Mono article or the Mono web site? —Preceding unsigned comment added by 129.176.151.10 (talk) 18:11, 17 June 2010 (UTC)

Agreed. This is a comparison of programming languages, not the platforms. While both languages are deeply integrated with their respective platforms (Java/.NET) the OS chart seems to ignore other implementations of the language. The chart should go, but for now I will just edit the ioncorrect columns. C# is available for Linux (no need to list every Linux distro). Java nor C# compilers are available for Android or Windows Mobile. You can cross-compile, but was the chart intended to demonstrate where compiled code will run? If that's the case it really does not belong in this article and should be moved to the platform comparisons. 83.94.199.190 (talk) 05:26, 25 June 2010 (UTC)

ok, but Mono does support only up to NET 2.0, that had to be mentioned Hervegirod (talk) 13:18, 26 June 2010 (UTC)

I am removing that entire section. The "runtime environments" are merely there for reference. This article is a comparison of programming languages - not runtime environments nor platforms. Please discuss here if you still believe this section belongs here. Useerup (talk) 18:30, 26 June 2010 (UTC)

I'd say it would be a relevant area for comparison as C#.net or Mono runs on ex. a Sony Ericsson W800i, something Java do, and oposite, C# Mono runs on iPhone os but not SE W800i. Platforms is definitley a place to compare on(as long as you don't start list all Linux Distros etc.) Thor erik ^{(talk|contrib)} 13:56, 22 July 2010 (UTC)

Yes, but the programming languages are not the VMs (JVM,CLR or Mono). Platforms on which the VMs will execute is definately interesting, but not in an article comparing programming languages . Such comparison belongs in the article comparing JVM with CLR. This article should also leave out the JVM/CLR as much as possible. But consider soft references. This is a Java platform feature which does not have any special syntax in Java. Nevertheless it *is* a concept intrinsically part of Java which directly affects how you program (not deploy). But including such features because they have direct influence on how you program with the language is not an argument for including the entire platforms and their targeted architectures in a programming language article. Useerup (talk) 05:06, 23 July 2010 (UTC)

Also your argument that C# Mono runs on iPhone os illustrate the very problem: No it does not. You can cross-compile C# using MonoTouch to produce native iOS executable capable of executing. In that sense, yes, C# can "run" on iOS. But then you would have to include every cross-compilation ability as well. I am sure that there exists some form cross-compilation for Java to iOS as well, at which point such extension arguments become moot because they become all-inclusive. Please try to keep this article a comparison between programming languages - not platforms. Useerup (talk) 05:12, 23 July 2010 (UTC)

Pointless restriction to convey obvious bias

Why the "language only" restriction? In a article between C# and Java, a comparison of "language features" without their respected platforms is totally pointless and misleading. Virtually everyone who uses Java uses the standard libraries and likewise for C# (.NET). You realistically can not make a useful comparison between the languages without understanding the platforms. For instance: this article lists C# as "green" for Linux, despite Mono implementing a fraction of .NET proper.

C# is not .NET. .NET is not C#. While I agree (see below) that the languages cannot be evaluated in isolation from their VMs and core libraries, that does not mean that you should pull in the entire stack. C# (the language) and CLR (the VM) along with the core libraries are clearly implemented by Mono and available on Linux.Useerup (talk) 22:24, 10 September 2010 (UTC)

I also question why suddenly now it was decided to remove the Collections comparison from the table. It was there for over a year. I think this clearly points to the bias in this article: before I added some collections Java has that .NET does not, no one seemed to care about this table. Why suddenly so much caring? Java's Collection Framework is actually quite good and well designed, somewhere where Java might have more "green" then C#. Oops! But when I did this (wrote in Collections that Java has that .NET doesn't, the whole table mas mysteriously removed. Suddenly it was "not relevant", I suppose.

I agree that the collections belong here (core library). At what point were they deleted? Useerup (talk) 22:24, 10 September 2010 (UTC)

Obviously having anything that would convey some sort of advantage to Java in a Java vs C# comparison would be a tragedy and must be removed with prejudice. Jbenjos (talk) 23:15, 9 September 2010 (UTC)

I think you should look over the recent edit you did and consider the correctness:

• You edited the table to say that C# does not have enums. Which is false: See section 1.10 of the C# language spec.
• You edited the table to say that C# does not have tuples. False.
• You edited the table to say that neither language use garbage collection. Clearly both languages are designed with GC in mind.
• You edited the table to say that C# does not feature events. False. Core feature of C# and is even supported by keywords. See section 10.8 of the C# language spec.
• You edited the table to say that C# does not have expression trees. False, this is a core feature of C#. See section 4.6 of C# language spec.
• You edited the table to say that C# does not have generic query language. False. C# has (context sensitive) keywords from, in, select (to name a few) to support a generic query language. See section 7.16 "Query Expressions" of the C# language spec.
• You edited the table to say that C# does not have a late-bound dynamic type. False. This type even has an alias dynamic. This type will also cause the compiler to accept any member access and generate code for late-bound semantics. All described in the C# language spec, section 4.2.3 and section 4.7.

I have reverted your edits, as they are clearly false. I will not make a guess on your motive, but I will encourage you to read up on the subject before doing sweeping edits. Useerup (talk) 22:24, 10 September 2010 (UTC)

I was following the "guidelines" the article sets. C# only has those features BECAUSE of .NET. Arguably you need at least the BCL to actually implement C#, and the standard seems to agree with that. I got no problem with that consideration. But the same can be said of Java, you need to have many classes implemented to properly implement Java. You seem to want to hold Java to one standard and C# to another. Which is why this article is a biased mess. Jbenjos (talk) 00:35, 12 September 2010 (UTC)

I think you may have misunderstood the points about a programming language. You cannot disregard parts of a language specification because you believe that they are only there "because" of .NET. Who are you to guess about intentions. And why should we disregard established language features just even if they are there to provide access to a platform (.NET) features?

The point is, the language has been factored differently. If one language provide something as a first-class language feature but the designers of the other language decided to put that into (a part of) the BCL, it would be grossly misleading to just tick a "no" for the latter language. At least it requires some qualification. So yes, I certainly support including references to some parts of the base class libraries for both languages. But we have to keep it in line and only include the necessary parts. The designers of the BCLs have again put different parts of platform support into BCL and extensions. This is still a comparison of programming languages. If we allow this to include comparisons of "dedicated enterprise server platform" it is clearly not a comparison between languages anymore.

I would be interested in your suggestion how to solve this. Do you think that enterprise servers belong here? Do you think that we should cut everything but what is directly mentioned by the language specifications? --Useerup (talk) 19:09, 14 September 2010 (UTC)

Numeric Applications and rectangular arrays?

I just removed the second sentence in this:

"In addition to this, C# can help mathematic applications with the checked and unchecked operators that allow to enable or disable run-time checking for arithmetic overflow for a region of code. It also offers rectangular arrays, that have advantages over regular nested arrays for certain applications.[18]"

This isn't true. C# provides a custom rectangular (or multidimensional) array syntax like this: "new Scalar[width, height]". However, that is basically functionally identical to what is commonly done in C++, Java, and C#: "new Scalar[width * height]". Also, the referenced .pdf paper was saying that most languages (such as Java which was mentioned) only have rectangular arrays and don't have direct language-level support for "block, symmetric, or sparse" arrays. I believe the author would consider Java to have rectangular arrays and that directly contradicts the rectangular array advantage for numeric applications mentioned in the Wikipedia entry.

Ramses89 (talk) 19:04, 28 September 2010 (UTC)

It seems to me that the referenced article exactly makes the point that true multidimensional arrays have an advantage over "nested" arrays which you must use if you have only single-dimensional arrays:

Quote from the article: "In many languages, including Java, it is assumed that it is sufficient to provide one-dimensional arrays as a basicdata structure. Multi-dimensional arrays can then be represented as arrays of arrays, also called the nested array representation."

The article goes on and enumerates a number of problems with nested arrays (arrays of arrays). It also says:

"Therefore, the one-dimensional array support that Java currently offers is considered to be insufficient to support large scale scientific computations and many researchers have proposed improvements on the array support in Java."

C# does indeed have true multidimensional arrays which has none of the drawbacks enumerated in the article. So it appears that you were incorrect that the article did not support the claim. Please change it back or (better) we could come up with a more precise phrasing - since it is not given that true multidimensional arrays *always* have advantagesd. In fact in most cases where array items are accessed in non-random order arrays of arrays will perform better. 83.94.199.190 (talk) 17:47, 29 September 2010 (UTC)

Generics and run time checking

To whoever made the edits claiming that C# does run-time type checking: I have reverted your edits because you are wrong. Java needs to put in type checks to be performed at runtime because of Javas type erasure. These checks are inserted into the code calling the methods of the generic. There is only one type in Java for each generic type: The raw type. C# generics are reified: There will be multiple "closed" type; one for each unique realization of the generic. The types methods and implementations are verified as type safe and need no extra type checks put into the calling ("client") code. Now, if you find the explanation in the article confusing let us discuss how to clarify. But please don't remove verifiable facts. Useerup (talk) 20:48, 7 October 2010 (UTC)

Why not syntax highlighting in Java code?

The C# code in the article is highlighted (but not Jave code) to give it a "nicer" feel. —Preceding unsigned comment added by 14.96.184.114 (talk) 22:49, 9 October 2010 (UTC)

I looked into this. The Java examples are indeed syntax highlighted. Java and C# has different "classes" with can be set on the source element. All of the code examples have correct classes ("Java" for Java and "csharp" for C#). The fact that Java appears less colorful is due to the wikipedia/-media definition for syntax highlighting. It is not something which can be addressed in this article. Useerup (talk) 15:25, 11 October 2010 (UTC)

The POV issues as I see them, and recommendations to resolve

The fundamental POV issue I see with this article is it seems to give the impression that C# is a better language then Java. How it accomplishes this is through a subjective idea of what is valid information in this article. I've tried to improve the neutrality of this article by spending a non-trivial amount of my own time adding things I believe are strengths of Java in comparison to .NET. However, more active editor(s) seem to be picking and choosing what features constitute "language features" and what features constitute "runtime features" within the context of this article, and quickly reverting any attempts I have made to make this article seem more balanced to the reader. These users will remove entire sections which they consider "runtime" features and reinstate others which in their opinion constitute "language features".

The problem at a fundamental level is not so much the separation of language and runtime for the purposes of comparison - it is that this kind of separation is not useful for a principled comparison. To make a analogy, it's like trying to useful comparison to car models based upon one or two of their major features, while picking this those features to promote a specific agenda in the comparison. You simply can not do this and remain neutral.

Even more concerning is that both C# and Java both rely on their respected runtime and standard libraries to derive language features! Separating runtime and language is an artificial separation, that's not entirely even possible. This is without regards to the fact that C# and Java programmers will be working with the respected standard libraries at such a deep level, such that ignoring their existence does not produce a realistic worldview of language capability.

Worse, this article gives the reader a incorrect perception about language comparison in general: that language features should be looked as a separate entity not alongside all the other capabilities of framework and tooling. Truth of the matter is, these things are as important if not more important then what is basically the built in syntactical macros of a language.

If you compare Java and .NET in the holistic manner, I am confident it is possible to create an article that is NPOV and truly shows the strengths and weaknesses of each camp with respect to each other. This article as it is, doesn't accomplish it. But it is certainly possible. Jbenjos (talk) 17:23, 17 October 2010 (UTC)

I would like to add that I agree with what was said above. After skimming the article - and the table takes up 40% thereof - I get an extraordinarily strong sense someone is trying to sell me something... I actually checked the title to see if this was "Learning Java for C Sharp Programmers"; sadly not. The table is very unbalanced towards C#, and the prose gives a feel of "This is C# does things; Java, on the other hand, does this." It's a very negative feel, perhaps someone with more knowledge on both languages should go about reworking the article. Timeroot (talk) 05:14, 18 October 2010 (UTC)

Would you agree that we should cut the table down (perhaps splitting it) to only incorporate features found in the language specifications? Useerup (talk) 11:20, 18 October 2010 (UTC)

That you read this article as "it seems to give the impression that C# is a better language then Java" is entirely subjective and not easily corrected. It cannot be a goal of this article to state that both languages are "equally good". It should not state that "C# is better" either. However, when it comes to features, it is a fact that C# offer more features than Java and this article should not try to hide that fact; rather it should try to convey it as neutral as possible. On the other hand I can see how the size of the feature comparison of the table may put excessive weight on the feature disparity. Useerup (talk) 11:19, 18 October 2010 (UTC)

It seems that you are arguing that all of Java SE (and EE?) should be allowed into this comparison, along with the entire .NET Framework? This I cannot agree with, for two very important reasons: 1) This comparison is still a comparison of programming langauges (Java and C#). Dragging in all sorts of framework features will add nothing to the principal subject. As I have said before, there are other articles on WP which compares the frameworks. Such comparisons belong there. 2) The article would become unruly big and the discussion on what to allow from each library would just continue (is ASP.NET MVC eligible? Entity Framework? Parallel LINQ?) further distracting from the primary subject. Useerup (talk) 11:19, 18 October 2010 (UTC)

Really, the baseline for this comparison should be the respective language specifications. In that sense this article has too much non-language related content. It is NOT our job to even out perceived "better than conclusions" by gradually dragging more and more of the stack built upon the languages. Useerup (talk) 11:19, 18 October 2010 (UTC)

Thus, I would suggest that we cut back on the features table and only incorporate those features directly mentioned in the respective language specifications. We should then refer to the framework comparisons 1) prominently in a disclaimer which also says not to take this as a platform comparison, and 2) whenever we tick a "no" for either language where the corresponding framework does offer some similar feature, we should qualify that "no" with a reference to that framework feature. Useerup (talk) 11:19, 18 October 2010 (UTC)

Perhaps we could also split up the comparison table into smaller sections and allow for a little more qualifying discussion of the features. Useerup (talk) 11:19, 18 October 2010 (UTC)

I have just given a very careful reading to the 'introduction' section. In the process, I promoted it to being the WP:LEDE (there wasn't one) and simplified some of the duplication I found (edit). It seems to me after that process that what the introduction was trying to say, even before I altered it, was that this is a parent article, and that Comparison of the Java and .NET platforms is a child article, per WP:SPINOUT. This makes perfect sense: if I was a young student trying to decide which of these languages to learn, or a system architect deciding which to employ in a new development, or a chief executive deciding which to specialise the whole business upon, then this is the article I would expect to start at - the one with the most general name. This should cover all the relevant bases, in SPINOUT style, with links to more detailed articles about the platforms, the platform extensions (like Java EE, NANT, what-have-you), the developer bases, the support networks, the libraries, the licences, the benchmarks, the runtimes, scalability, everything. Two things we should not say here are (1) this is only about the curly braces and the while loop syntax; (2) This article is nearly finished. --Nigelj (talk) 12:18, 18 October 2010 (UTC)

Thanks, Nigelj. Given SPINOUT would you agree that we should cut back on this article to concentrate on the languages as they are described in their respective specifications? Also, I would consider this page a spinout (child page) from/of the more general comparison of platforms - as the programming languages are generally taken as being parts of the platforms. Useerup (talk) 13:15, 18 October 2010 (UTC)

Tuples

I tried finding something about tuples and C# on Google, but it just seems as if it's a normal object with two generic arguments? Doesn't Java have that as well? —Preceding unsigned comment added by 85.229.222.130 (talk) 16:16, 23 October 2010 (UTC)

Actually it is an object type with from 1 to 8 numbered slots for other objects. I suppose that you are correct that a similar type could be specified in Java as well, except for the problems which would arise from type erasure. But perhaps more importantly, this is not primarily a C# feature; rather it is a .NET 4.0 feature (System.Tuple). There is no specific feature of C# which is directly linked to tuples. In that it is very comparable to java.util.Date which is a very common type which could be specified using the language itself. This ties into the discussion above: When is a feature a language feature? When is a feature/type eligible for being mentioned in a language comparison? Useerup (talk) 18:00, 23 October 2010 (UTC)

Indeed. At least in my opinion, if it is a .NET feature, then it's technically not a language feature? I don't know where to draw the line, and as demonstrated by the above discussions, many others doesn't either. What java. packages are to be considerd langauage features? Perhaps there should be a new article which compares the .NET platform with the entire, officially specified Java Platform? (http://jcp.org/en/jsr/overview)85.229.222.130 (talk) 18:43, 23 October 2010 (UTC)

Ahh, never mind. Just checked, and there were already a comparison of the Java and .NET platforms. —Preceding unsigned comment added by 85.229.222.130 (talk) 18:44, 23 October 2010 (UTC)

You cannot find the Tuple type in the C# language specification. On the other hand, it is in the System namespace which could be said to roughly correspond to java.lang.*. You will also not find java.util.Date in the Java language specification. I suspect that an article like this one will always tend to bloat because you will have readers/contributors trying to make up for perceived lack of features by dragging in more topics where they believe their stack of choice will look better. That is why we saw "enterprise" features and "enterprise servers" included at some point. It is also the reason why we now have the "platform" madness. My personal position is that most of those topics belong in another article. The real challenge is to draw up some reasonable and objective rules for what belongs here and what does not. I don't have the answer to that, but I believe that barring any other agreement, we should just cut to the bone and jettison anything not in the language specifications (for features). It is true that we would then have some features for which would have a "no" for one or the other languages knowing that the very feature is offered by the base class library (BCL) instead. I believe we should allow that, but that we should qualify those "no"s pointing out that this is a library feature instead. Useerup (talk) 19:57, 23 October 2010 (UTC)

Platform support

Recently the platform support was edited to show "partial" for C# on a number of platforms because the latest version of C# "wasn't even available" on those platforms. That was correct. Mono C# 4.0 has now been released for a number of platforms and I edited the platforms covered by Mono.

This was promptly reverted with a reference to "C# support on non Windows platforms is partial, because Mono does not support all of .NET framework (WPF, etc...))". I am sorry, but this article is still about C# and Java (the language) and not the .NET Framework or JRE. Developers developing games for iOS are very much programming in C# - but need not use the .NET Framework. Please help keep this article about the languages and take the library comparisons to comparison of .NET and Java. Thanks. Useerup (talk) 00:52, 25 October 2010 (UTC)

In that case, we should not compare the platforms support, because if we want to compare languages as you say, platforms are not part of the equation. Besides, we don't have all the (non standardized) C# libraries on non Windows platforms, because Mono does not implement all of C# 4.0. But if we think that it's not a problem, then a lot of the comparisons must be removed too. For example P/Invoke or LINQ are not part of C# - the language, as standardized. However, the article deals about the COM integration, which has nothing to do with C# as a language. I think there is a kind of double standard here. Hervegirod (talk) 21:04, 25 October 2010 (UTC)

Oh, I could not agree more. In my opinion we should cut this article down to what can be found in the respective language specifications (see above). There is already separate articles for comparison of the VMs/platforms and for the frameworks/class libraries. This article has a tendency to grow far beyond the languages and I fear that it is because some editors want to introduce features where they believe their stack of choice has an advantage, which quickly becomes a local arms race. I would welcome a process where we cut down the table and feature discussions (possibly spinning them out or moving them to other articles). The "double standard" is just a consequence of the tendency to introduce features to "even out" the comparison. But cutting to the core still leaves many grey areas: For instance, the article was recently expanded with both collection classes and platforms. Collection classes are not part of the language, but in the case of C# some of the collection interfaces are actually unified with arrays (implemented by all arrays) which are very much part of the language specs. Correspondingly in Java the for loop have been extended to accept an interface for iterating through collections, so the for loop has a dependency to the iterable interfaces as well which brings it preciously close to collections. IMO collections should not be here though. Similarly with platforms: They were initially introduced demonstrating that Java existed on a number of platforms where C# did not. But how does a programming language support a platform? If there exists a cross-compiler, certainly a developer can use the language to develop for that platform. Like Android. But then the entire platforms section becomes moot. IMO that comparison belongs in the comparison of the .NET and Java platforms where it can be properly qualified. In this context it just doesn't make sense. Useerup (talk) 22:09, 25 October 2010 (UTC)

The JVM can run on iOS, by the way. Changed that back. 85.229.218.52 (talk) 20:08, 7 November 2010 (UTC)

No, the JVM does *not* run on iOS. Please cite any authority for that claim. BTW, JVM need not run on iOS, all you need to reference is some cross-compiler for iOS (like Mono has a cross-compiler for C# to iOS), but so far no reliable source on that. Reverting. Useerup (talk) 21:20, 7 November 2010 (UTC)

JamVM (http://jamvm.sourceforge.net/) runs on the iPhone: "ARM: built using unofficial toolchain and tested on a jailbroken iPhone.". Tested myself, requires a jailbroken iOS, but it sure runs. 85.229.218.243 (talk) 15:48, 24 November 2010 (UTC)

Reverted again. Multiple issues: "Tested myself" violates WP:NOR. An unofficial toolchain doesn't cut it, a jailbroken iPhone cannot be considered an iOS device. Useerup (talk) 09:11, 28 November 2010 (UTC)

Operator support in Javas arbitrary size decimals and integers

Java does not support operators with these types. You cannot use the + or * operators, you have to use the member functions instead. This is an important difference between Javas types and the C# ones. Useerup (talk) 09:30, 28 November 2010 (UTC)

Obviously the authors of this article are closed microsoft tools developers

Why is c# Listed as being supported on practically every platform that Java is ? What a load of rubbish..

C# on Linux, there is Mono but that is _NOT_ feature complete and is completely reliant on the Mono project. Linux support is partial which also means all other platforms that have mono/c# listed should be marked as partial. —Preceding unsigned comment added by 92.7.92.232 (talk) 09:27, 27 October 2010 (UTC)

Check your sources before claiming something. C# is feature complete on Mono. .NET however, is not. And since this is a comparison of programming languages, .NET is irrelevant.

http://www.mono-project.com/Compatibility GeirGrusom (talk) 12:01, 26 February 2011 (UTC)

I don't know how C# can be marked as feature complete when .NET is not. If I want to use WPF with C# on Mono, I can't, for example. Hervegirod (talk) 16:01, 26 February 2011 (UTC)

Please read what GeirGrusom wrote. This is a programming language comparison, not a comparison between the full .NET and Java stacks. By your logic, Java is not feature complete on Android because you cannot use Swing. Clearly I *can* use Java (the programming language) to develop for Android, I just cannot use the entire JSE stack Useerup (talk) 08:05, 6 March 2011 (UTC)

Conditional Compilation

Java does support conditional compilation, in the form:

if (CONDITION) {
    // conditional code
}

Where CONDITION is an expression that can be evaluated at runtime (for example, using a static-final boolean). If CONDITION is true, the "if" portion of the code will be removed, and only the body left. If false, the entire block will be removed.

This is not simply a matter of the compiler performing an optimization. The usual Java "no unreachable code" rule is suspended in this situation specifically so it can be used for conditional compilation. Spockwithabeard (talk) 18:25, 13 February 2011 (UTC)

That hardly qualifies as conditional compilation, though. It is in fact just an artifact of dead code removal. You cannot - for instance - control the conditional compilation by a compiler switch. Nor can you conditionally define classes, interfaces or members. You cannot conditionally define metadata (annotations). All of these are possible with what is understood as conditional compilation. Useerup (talk) 08:12, 6 March 2011 (UTC)

Instance Initializers

This seems to have been translated (incorrectly) for another language.

In addition, Java knows the so called instance initializers, which are block with similar function than constructors, except that they contain no code.

Perhaps the correct text would read,

In addition, Java has so-called "instance initializers." These are in a block which is similar in function to a constructor, except that an instance initializer block contains no procedural code."

I can't vouch that that is technically correct. However, the verb "know" in this context doesn't seem meaningful. Also, "similar than" is not a valid English idiom, and therefore ambiguous. —Preceding unsigned comment added by 74.221.134.210 (talk) 23:10, 30 March 2010 (UTC)

I'm not sure what is asserted by the phrase "they contain no code". They certainly can, with one or two restrictions (it cannot contain a return statement, for example). I would also suggest that the term "so-called" is emotive.

For those interested, instance initializers are a way of including a common portion of code into all of the class's constructors. After compilation, the initializer has no separate existance, it's code having been duplicated into the begining of each constructor. Spockwithabeard (talk) 18:46, 13 February 2011 (UTC)

Maybe I'm not quite grasping this right, but C# does have instance initialisers. They are of the form:

[protection level identifier] [Class Name]([input variables]){[method]}

See: http://msdn.microsoft.com/en-us/library/k6sa6h87.aspx for examples. SEoF (talk) 13:29, 6 September 2010 (UTC)

Hi SEoF, the feature you reference is a constructor. Instance initializers (at least as they exist in Java) are unnamed methods which run before the constructors are executed when creating a new instance. These methods can be used to set defaults. So a constructor is not quite the same thing. I believe that this is a Java-only feature. C# does have static initializers (as does Java). --Useerup (talk) 22:42, 10 September 2010 (UTC)

POV Bias

Marked page as being biased. It seems to favor the C# programming language through use of C# favored syntax and through accepting the principle that "more is better" which is a matter of dispute. —Preceding unsigned comment added by 74.211.226.162 (talk) 00:53, 31 December 2009 (UTC)

At least according to the text, most of the instances where it uses the C# syntax are instances where only C# supports that particular language feature. I wouldn't call that a POV problem; you can't somehow illustrate a C# only feature with Java by definition. I suppose you could include Java code that replicates the functionality (many of the C# features are syntactic sugar that compiles to roughly equivalent byte code), but harping on the verbosity required in Java to replicate a bit of C# syntactic sugar is likely to annoy Java coders more (particularly since in many cases a limited version of the C# functionality can be replicated non-verbosely).

As for indicating that "more is better", this is a language comparison. Having or not having a feature is directly within the scope of the article, and I see few circumstances where Java is denigrated for lacking a particular feature. In the Language history and evolution section, they do point out that there is debate over which language's approach is superior. What specific lines bother you? Marking a long article as POV over a matter of a few sentences is overkill; fix the POV, don't red letter the article.

Disclaimer: I've coded in both C# and Java professionally for a few years each. While I slightly favor C#, I do find the explosion of single purposes syntax since .NET 2.0 to be a bit overwhelming. I don't see much in the way of POV, but I suppose my slight C# bias could be a problem. —ShadowRanger ^(talk|stalk) 17:41, 4 January 2010 (UTC)

This article certainly does have a POV bias. Just the categories in the table have a strong choice towards C#. Just look at a category called "Delegates". I mean come on, Microsoft invented it and put it in .NET, and now it gets compared... Hmmm, maybe there should be a category called "Java Beans" Java = yes; C# = no 141.189.251.1 (talk) —Preceding undated comment added 11:56, 14 July 2010 (UTC).

The category is actually called "delegates/method references". Delegate may be Microsofts term for method references, but Java does not AFAIK have such a concept. Method references are not unheard of in other languages, like e.g. C++ which features both direct function pointers as well as pointers to members - where a member can be a method. Would you prefer to delete the "Delegate" word and just leave the "method reference" or perhaps "method reference/pointers"? That would be ok, I suppose. Your suggestion for Java Beans is a little far fetched, though. Firstly, JB is not a language feature, it is a coding/tooling convention. Secondly you would have to qualify with some neutral alternative, like, say, properties? If you feel that some of the terms used are MS marketing terms, feel free to change them into a more neutral language. Useerup (talk) 20:09, 18 July 2010 (UTC)

Seriously, I read this article as a Java favoring programmer who works in a C# shop. I believe the title should be changed to "Comparison of things C Sharp can do that Java Can Not." 64.90.193.188 (talk) 19:16, 18 October 2010 (UTC)

I would have to agree this is POV bias here. There are items that are considered features in the C# column, but Java intentional left it out. Example unsigned integers. Also the color scheme is conveying message red is bad, green is good. Which is fine if you working in marketing, but this is suppose to be subjective comparison, using emotional colors to depose someone to accept your conclusion is logical fallacy(see glitter generality). Actually I am going to remove the colors, I just proved why to remove them. No arguing, prove your point. —Preceding unsigned comment added by 208.102.251.122 (talk) 16:50, 20 October 2010 (UTC)

Does Java feature unsigned integers? no. Does C# feature unsigned integers? yes. Are they relevant/useful? Yes, for some types of applications like: 1) low level applications binding to native APIs which use unsigned integers/longs or 2) bit/byte processing of streams. Operations such as shift/rotate become more consistent and less prone for errors when they can be manipulated in their raw (unsigned) form. Should the topic be discussed at all in this article? Join the discussion at the bottom of this page, please. Useerup (talk) 23:32, 21 October 2010 (UTC)

Hmmm... I believe that neither C# nor Java has bit-rotation operators. And Java has a separate "unsigned shift" operator to get around this issue. That's the problem of making such a simplistic comparison on a feature-by-feature basis. Spockwithabeard (talk) 18:56, 13 February 2011 (UTC)

You completely missed the point, java left out unsigned integers by design. http://www.gotw.ca/publications/c_family_interview.htm . The might add it in the future, but you cannot go out saying it doesn't have X , and act like it is negative when they pulled it out for a reason, not that they couldn't have unsigned integers.

red/green is standard for features of comparison articles. See for instance Comparison_of_archive_formats. Or see the Category:Software comparisons. No point in trying to hide the fact that some features are not supported by on language and not by the other and vice versa. It's better to qualify the "no" if you feel that it misrepresents the actual state of the language. Useerup (talk) 23:32, 21 October 2010 (UTC)

You just provided a example and not an actual proof of anything. Basic argument is Statement X, Reasones 1,2,3 supporting Statement X. Just merely providing examples of something doesn't prove your point. Here is list of colors and what the do to emotions of people http://colour-emotion.co.uk/whats.html . You can see who runs the site, and it isn't some bogus site on the internet. There are links to many research articles on the effects of colors and emotions. In the table colors are being used, which inflicts emotions on person, thus you are using logical fallacy in your presentation. I wouldn't mind neutral colors, but the red and green are not neutral at all, quite the opposite and the research supports my argument, not yours.

Response: I am sorry you don't like the colors. Please file a complaint with WikiPedia. Feel free to quote that article about colors. This article has not redefined the color schemes for the templates. If WikiPedia changes the templates to convey alternate colors for "yes" and "no", those changes will take immediate effect in this article. Incidentally, I did not only provide you with "an example". I pointed you to an entire category of articles, and an official category at that. Poke around the articles in that category and you will find that almost *all* of them use the yes/no templates for features for which you can answer yes or no. Claiming that this particular article or section is POV because it uses standard WP templates is disingenuous. Now, I recognize that sometimes you can formulate a feature in such a way that it becomes POV, e.g. "open source yes/no". Open source is just a specific license type and the NPOV variant would be to change the feature into "license model" and list the license types (this is just an example not pertaining to this article). If you do see such issues here then by all means point them out or change them into NPOV. This article may need some section on simplicity versus features to counter the weight of the feature table - or the feature table should be cut down to bare bones language features to reduce its weight. Please join that discussion below. Useerup (talk) 12:55, 23 October 2010 (UTC)

Response: Ah what don't you really understand? You provided a link to example of comparison of archive formats, this is logical fallacy , or false logic. Proof_by_example or hasty generalization see Fallacy for more information on fallacies, I really don't have time for logical nonsense. Both articles you listed do not support your conclusion , can you quote them , I do not see anything, just magic hand waving , its over here somewhere. And saying well wikipedia does it therefore it is right, is again another logical fallacy, appeal to popularity,see Argumentum_ad_populum.

Your comment " I am sorry you don't like colors " again is just an Ad_hominem , or personal attack. Finally you have distorted my argument so much you know have another fallacy a straw man Straw_man . You didn't address the colors issue , you just dismissed it as personal opinion without anything to back you up. I can go through and put all kinds of examples on wikipedia where colors are not used but I do not do that because I realize this is false logic. Stick to the argument , to don't hand waving.

Response: Authors of this article did not choose the colors. They were given. I did not give you two examples, I gave you one example and then pointed you to an entire category of comparison articles: Category:Software comparisons. It is an official WikiPedia category. 100% of the articles in that category (and any other comparison category) use the very same templates as this one. Again, I am sorry you don't like the colors, but it happens to be the colors chosen by WikiPedia. Pointing that out is not an ad hominem, so ease up, please. These are not just examples, this is a policy. You are complaining about a general issue (template definition for "yes" and "no") and this specific article is not the place. Useerup (talk) 21:34, 25 October 2010 (UTC)

Response: Did you look at your own link Category:Software comparisons, in many of the examples of software comparisons the tables do no use colors, just simple yes or no, not colors. I am not the only one that has raised issue about the coloring on the comparison. I have brought evidence to support my claim in that colors induce emotional on the reader of the article and if this is purely facts based comparison, the coloring should be left out or have neutral colors. You yet to address this and keep point to articles that are examples of which not all your examples support your own conclusion.

I actually looked through enough of the articles in that category. Every single one I opened used the same templates. It is definitely the norm. I cannot believe that you have the audacity to claim otherwise. Keep in mind that everyone who reads this discussion will do the same. If you don't like it you should direct your complaint at WikiPedias templates. Or get over it.

Response: http://en.wiki.x.io/wiki/Comparison_of_ADO_and_ADO.NET , simple elegant, and proves you wrong. Dam never say everyone or all or "it's the norm" . And if you take a look at a majority of your examples, they are comparing multiple items, not just two. So examples pretty much all fall apart. Again you didn't address the points. More than just me has raise issues with the coloring but you alone are over ruling everyone. My points are clear, my support is clear, and you keep giving nonsense examples as counter points saying "looky over here there the same" , when in fact there not the same. It goes back to sesame street one of these is not like the others. And I really don't care about all the examples, I am going for neutral , un-bias article, not a some C# promotional marketing on wikipedia.

Again, no. This article is a comparison article and like all of the articles in Category:Software comparisons the yes/no template is appropriate. Do you want to change all of those articles? Useerup (talk) 23:55, 25 October 2010 (UTC)

Your wrong give it up, nothing further. Not once have you addressed any of the points made, and I am not the only one that has said the coloring is bad thing, but you continue to stick your nose in the air. I brought up a link from you Category:Software comparisons that disproves your argument. You said looky over here they ALL do it , and I found one that does not, pretty simple it is called proof by contradiction,look it up some time. I pointing out your argument that just because everyone does something doesn't make it correct,but you dismissed it. —Preceding unsigned comment added by Bongey (talk • contribs) 14:58, 26 October 2010 (UTC)

Well I reverted the personal attack. I am asking you to work with me on this. I program in both languages, and I do think C# is way ahead of Java right now. And if oracle doesn't get there head out of their ass C# will take over in a lot of areas. I don't like the coloring because it injects emotion into the reader. Let the reader make the decision that C# is better on their own, don't use coloring to lead them to your conclusion. I just want an unbias, just the facts type of comparison. The comparison should also be limited to features find important in more than one language. It is alright to put value types description of C# but I wouldn't go as far to say that they are really great feature that everyone wants, nor have I ever seen any other languages requesting something like value types.Bongey (talk) 15:24, 26 October 2010 (UTC)

I apologize for letting so much time pass before responding. Busy doing other things. I will certainly work with you, and contrary to what you may believe I don't believe the purpose of this article should be to demonstrate that "C# is way ahead". We need to report verifiable facts as reported by other sources. I would go for a "checkmark/blank" or another form to graphically convey "yes/no". But as it stands this really is the way comparison articles are presented on WP. The yes/no templates autimatically color the cells that way. I don't believe that *this* article is the place to change that. While we're at it, you could also complain that "checkmark/minus" induces an emotion. Or that yes/no does. On the topic of value types, I really cannot believe that we have this discussion. Check out C++ automatic variables. Or the age-old Pascal "record" type. or... Stack allocated copy-semantic structures really are a very common occurrence outside Java. Now, I too feel that the table is somewhat monumental. I believe that if we pruned it of anything not directly language oriented and split it up into several tables followed by the descriptions (which are already there) it would go a long way. How about that? Useerup (talk) 21:10, 4 November 2010 (UTC)

Also please do not undo an item until the dispute is resolved. Just making a statement and undoing something is trolling. —Preceding unsigned comment added by Bongey (talk • contribs) 16:17, 22 October 2010 (UTC)

I will wait to remove the content but the document needs to reference features also, for every feature it must have outside reference, not a reference to wiki article or somewhere on the page. If a feature was left out on purpose in the language it should not be NO , but remove on purpose or something. —Preceding unsigned comment added by 208.102.251.122 (talk) 16:55, 20 October 2010 (UTC)

You need to read up on wikipedia requirements. No, not every feature *needs* to have a reference. It merely should be possible to find such a reference. See Verifiability. Useerup (talk) 23:32, 21 October 2010 (UTC)

The section about primitive types are bias again, there are value types in C# which so simliar to primative types in java , what is the point in making the distinction. see http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx Here what is the point of acting like it is object when it doesn't support basic object oriented features.

Unlike with reference types, you cannot derive a new type from a value type. However, like reference types, structs can implement interfaces.

Unlike reference types, a value type cannot contain the null value. However, the nullable types feature does allow for values types to be assigned to null. —Preceding unsigned comment added by 208.102.251.122 (talk) 17:11, 20 October 2010 (UTC)

Value types (types defined using struct) support encapsulation, member/instance methods, properties and can implement interfaces. Javas primitive types doesn't support any of those concepts. In C# the "primitive" types are merely value types and the developer can declare new custom value types. In Java there's a fixed number of primitive types. Developers can not define new primitive types in Java.

Seems to me that there are plenty of significant differences, right? Useerup (talk) 23:38, 21 October 2010 (UTC)

value types are also some kind of syntactic sugar, because when you pass a value type in a method which accept only a reference type (a regular instance, as in Java), C# has to do boxing / unboxing under the hood. It's exactly as if you had a special mutable object which you use to hold the primitive value. In fact, I think that it's exactly the way C# works. So when you think that you are creating a new primitive type in C#, in fact, you are creating a new kind of mutable object which contains a value of this primitive type. And custom value types as structs is really is way of holding more than one primitive value in the associated Object. And as it is boxed / unboxed, performance can suffer because of that. Syntactic sugar. Hervegirod (talk) 22:01, 25 October 2010 (UTC)

This section is getting messy and this discussion i leaving the POV and "color" discussion. I created a new section "Value types" below, please see my response there. Useerup (talk) 22:26, 25 October 2010 (UTC)

You cannot extend value types, so it doesn't really matter. At that point you are creating new object that you cannot extend, so what would be the point? I created value type Hat, I cannot extend value type Hat to create new object Cowboy Hat, so now you don't really have polymorphism either. It is that simple. Doesn't really matter because they don't support one of the most basic features of being object oriented feature which is inheritance. So many books start off showing you why inheritance is a good feature, but your value types cannot do this. To say C# is completely object oriented language by introducing a bastardized primitive type that is mixed with some OO features is downright lie.Sun seen that they couldn't really get around this problem, so that is why they did it this way.

Response: Read the article you linked to yourself below. Extension mechanism or polymorphism is not a requirement for OO. If you want to see examples of how value types "matter" look up how the .NET DateTime and TimeSpan types are defined. Those are types with encapsulation. You can add a TimeSpan to a DateTime and the result is a new DateTime. Yes you could do something similar in Java (sans operators) but then you would have to use the trick using immutable classes. DateTime and TimeSpan does not have to be immutable in C# because they are value types. Decimal is another example of a value type. What you are saying amounts to: "because I do not see how value types can be useful, mentioning them in a comparison article is POV". Sorry, but that is not the criteria. It is correct that Sun considered unsigned integer types and rejected them as a matter of opinion. Gosling is on record claiming that he does not believe that developers will be able to use them correctly. Seems to me that right there is a legitimate and interesting difference between the languages. I think it would be a good idea to qualify the "no" with a link to that discussion. Useerup (talk) 12:10, 23 October 2010 (UTC)

:Response: Did you read the article , or you blinders on ? Quote from the article "Languages designed mainly for OO programming, but with some procedural elements. Examples: C++, C#, Java, Python." C # is not consider a pure OO language. From the article "Fundamental concepts and features" both Subtype polymorphism and Object inheritance (or delegation) is missing from value types. Finally the point is the types are not OO types, they are just some mixed up type that is not a pure OO type. Trying to make the distinction that some how the value types are signifactly better than or different that primitive types in java is nonsense. Value types is not found in any computer science literature, outside of Redmond, that being said the same could be said of primitive types in java, but you cannot make the jump since MS made up some fancy non OO type that is somehow a great feature that it is in the language. It would be fine to put in its own article describing C# but to make the jump that since MS made up this mixed up OO type that is great feature, as in more is better, but value types are not defined outside .NET . Just try google value type definition, you only find references to C#. Finally here is MS own magazine stating that value types act like primitive types,(value) type acts like a primitive type. http://msdn.microsoft.com/en-us/magazine/cc301569.aspx

Again, I think you are missing the point. A kind of type in C# does not have to be an object type deserve an entry in this article. It doesn't matter whether it supports inheritance or not. The point is that C# value types are very different from Javas primitive types: In C# you can create new value types, in fact the mechanism and the type integration features are such that the built-in simple types are not "magic": They can be built using the language itself. In Java primitive types are a fixed set of "magical" types, which also are not unified with the reference types. In C# value types supports encapsulation, member methods, properties and even constructors. But most importantly (because it goes directly to your claim that "it doesn't really matter": Value types are important enough that they have been used to implement DateTime, complex numbers etc. To say that "they are just like Java primitive types" is a gross simplification. To dismiss them because you don't think they are OO is a logical fallacy: They still represent a significant difference between Java and C#, hence they belong here. Would it be clearer if we changed the title from "Value types" to "Custom value types"? Finally, if you want to discuss what types are objects I'll be happy to, but please open another section for that, this one is getting messy. Useerup (talk) 21:34, 25 October 2010 (UTC)

Response: So you are saying that they are just special type of object, that makes it easy with syntax sugar, therefore they are not a actual language feature. What is to keep me from writing something in java to do the same thing , the JVM wouldn't support it like .NET, but now your in problem. The problem is that the language feature exists because of the .NET runtime. The value type just allows access special functionality of .NET runtime, not that feature is pure language concept.

No, I am not saying "they are just a special type of object". Quit putting words into my mouth. Read up on the subject. Value types are certainly not syntactic sugar. And even it they were, syntactic sugar is very much present in all programming languages, and it matters. Loops are syntactic sugar for conditional branches! And no, I am not "in problem". You should read up how stacks such as Java and C# are built (hint: In the bottom the VMs, on top of that the languages *and* some core libraries, and on top of those the base class libraries). The raison d'etre of any programming language is exactly to expose the underlying system with a higher level of abstraction. Syntactic sugar, if you will. Useerup (talk) 22:53, 25 October 2010 (UTC)

You cannot say something is OO and miss basic features of being OO see http://en.wiki.x.io/wiki/Object-oriented_programming.

Response: Now read that article and see how the basic requirement of 'object orientation' is about member fields and methods. Inheritance (aka extension, subclassing) is described as "may". Consider how JavaScript is clearly object-oriented but does not have class-based inheritance at all. Anyway this is completely besides the point. A feature is not required to support inheritance to be mentioned in this article. The feature must meet some type of notoriety criteria. As this specific feature (value types) have already been used within the BCL framework to create types for DateTime, complex numbers, decimal/financial type etc, it clearly has significant value (no pun intended). That you fail to see how it can be used does not mean that it is POV. Simple as that. —Preceding unsigned comment added by Useerup (talk • contribs) 11:51, 23 October 2010 (UTC)

Please don't undo the dispute in the section until this is resolved.

The dispute is about Neutral Point of View. I have removed that because this is about how to use a specific set of features and I see no bearing on POV - except possibly what is already covered by the POV marking of the entire article.

Extension is not a requirement for object-orientation. Encapsulation (member methods and encapsulated state) is. Value types fulfills that. Beyond that, computer science recognizes more kinds of types than classical (Java-centric) classes. In C# value types are not class-based, but they support a number of other type-integration features such as explicit/implicit conversions, operator overloading. That you with your imagination cannot fathom how value types could be useful because they cannot be extended does not mean that the feature does not meet the notoriety criteria for appearing here. Can you say complex numbers, vectors (the mathematical variety)? Financial data types. There are many use cases for which value types are a better fit than classes. Indeed all types where you cannot say the instances have identity - like simple numbers, complex numbers, distances, time etc.

If you want a POV tag in these sections then you must state what the problem is with those sections. I recognize that there are some who question the "weight" of the entire article. That is still an unresolved dispute and I encourage you to join the discussion below. But these sections are already covered by the article POV tage and you have not stated anything POV specific to these sections, except for misunderstandings about how the C# feature works. Useerup (talk) 11:38, 23 October 2010 (UTC)

Response: You are just dismissing the arguments,and you follow them up with logical fallacies. Finally this being said , there many comments in saying this article is POV bias, but someone how you alone are dismissing them. The overall article has POV bias , I bringing up certian points and you pretty much dismissing all of them, without any real logic/or reasoning behind you statements. You haven't quoted any articles nor have you linked to any independent articles outside of wikipedia to support your conclusions. I will not put the tags in the article because you are correct it is the wrong tag, but I do not find it constructive if the length of the article is very long, you miss the POV tag at the beginning.

Why is this article a comparison of features when there have been several points cited that the architectures were tackled completely differently? The two languages are superficially similar, both in syntax and in architecture, and their conceptualizations are identical(Pure OO with single base class/multi interface inheritance, ad-hoc polymorphism, Garbage Collection and compilation to an intermediate byte code that is constructed to a VM that jits the byte code to native code, decoupling implementation and design, allowing for code-once debug anywhere methedologies). The identical structure is nice since it gives you the ability to code an abstract model and then implement the model in either language, but doing anything particularly advanced in the language is highly-non trivial and I as a C# dev would be lost in the advanced idioms in Java, and if a Java programmer can just read a complicated Linq query, then they are by definition as much a C# dev as me. To summarize, I feel we need validation of why a comparison is reasonable, and then we need a validation of why comparison of features is reasonable.

Side note on the table, that table read very biased to me as a C# dev in favor of C#. In particular it seemed that typed function pointers(delegates in C#), one of the most advanced features of C#, was really milked for all it's worth. Java has an idiom to emulate delegates, but it neither mechanically nor semantically is quite the same(in particular delegates in C# are not hugely idiomatic, the idiom in Java is so idiomatic I actually know it, and I don't code in Java). The addition of delegates opens up completely new design patterns(functional ones, usually), and as a result is a huge deal that can be milked. But that table seems to represent a half dozen features that are all really just "C# has function pointers". A number of the rest of the features could be summarized as "C# has a true top type for all types in safe code", which Java doesn't(and I am not saying that is a bad thing, but from a type-theoretic standpoint it is true. The safe code is a caveat that has to be added since the formal semantics of certain things pointers do, afaik, is not defined which is why they are made to be completely outside the type system, pointers should from a type theoretic view should not be assignment compatible to object so they aren't. A better rephrasing might be "all items that should, from a type theoretic stand point, be assignment compatible to object, are." Although this would imply that there aren't any flaws with the type system, which isn't true.) This also summarizes the issue with struct types, whether or not pass by value types in C# are or are not in the realm of OO design I don't care to get into, but they are assignment compatible object in C#, and they are not in Java(although the new auto-promotion feature will give them some syntatic sugar to help with that.) Further on this, struct types are in the CLR, and do NOT get auto-boxed, they work, under the hood, quite differently(dig through the IL if you don't believe me. I thought this was how it worked as well, but it isn't(it would lead to bizarre performance characteristics if it did.) LCpdx (talk) 22:15, 11 December 2010 (UTC)

Bias?

Have to agree with some previous writers, the whole article sounds like something from Microsoft's PR department.85.229.221.1 (talk) 08:00, 1 August 2010 (UTC)

I have been reading it, and sounds exactly like what you are pointing. —Preceding unsigned comment added by 217.207.165.222 (talk • contribs)

I suggest a bit more precision in your critique. Which lines/sections bothers you? Use of weasel words? Have anything important about Java been left out? Is there a weight issue where you believe that too much importance is put on an area where C# comes out looking better while areas where Java might look better have been skipped? If you point out what you see as problematic maybe we can fix it. 83.94.199.190 (talk) 12:15, 6 August 2010 (UTC)

In my opinion, listing both "implicit conversions" and "explicit conversions" doesn't make sense. Sure, they are both features in a sense, but they still perform the exact same thing (if I understood them correctly). Perhaps those should be combined? Also, it seems that the "events" feature just consists of hiding a few words of code - the same can be accomplished in Java with some extra characters, or am I missing something? Also, can't the "properties" feature be accomplished using the standard JavaBeans framework? 85.229.220.150 (talk) 16:49, 13 August 2010 (UTC)

Implicit conversions are akin to integer promotion where - when choosing between overloaded methods - the compiler may promote an int to become a long in order to match the parameter types. Explicit conversions are merely a way to define how exactly an explicit type-cast will be performed. Thus implicit conversions have impact how the compiler chooses between overloads of a method. They are used to integrate a type in with the rest of the type system, like e.g. the decimal type. Explicit and implicit conversions are distinct features with distinct and different purposes, although they perform similar and comparambe functions. You can compare to inner classes. C# has one type of inner classes, Java has anonymous and instance-level inner classes. You would want to collapse those into inner classes either, would you? That would not represent anonymous inner classes fairly because they *are* a distinct feature which is used for different purposes compared to other inner classes. 83.94.199.190 (talk) 17:02, 14 August 2010 (UTC)

If someone briefly skims the article and mentally associates "green" with "good" then I can see how the article would appear biased toward C#. But a design principle of Java has always been to keep the language "simple", while C# has seen an explosion of features since 2.0. Some see this as a flaw in C# because it becomes that much harder to master the core language and to share code between people with different coding styles and experience. I think it would be improper (and not unbiased) to try to balance the greens and reds because it would give the false impression that the languages have similar complexities. I would not oppose a disclaimer reminding the reader that the sheer number of features is not very significant when comparing languages. I'm also interested in any ideas on how to reduce the tables altogether without losing the information. Maghnus (talk) 21:58, 14 August 2010 (UTC)

(By the way, I'm just referring to the tables and haven't read all of the prose. Sorry if I overlooked a lot of blatant bias there...) Maghnus (talk) 22:02, 14 August 2010 (UTC)

Simple vs. complex is an interesting discussion. I fear that it may not be as clear-cut as some may believe. Just having more features does not necessarily mean that a language is more complex. And even when you can consider a language more complex you'd still have to weigh that against the complexity it removed from other areas. Case in point: C#'s marshalling when calling native APIs. Yes, it is an "extra" feature to consider, but it does make calling native APIs considerable less complex. Useerup (talk) 11:25, 15 August 2010 (UTC)

You also have to consider orthogonality, i.e. how well integrated the features are, how cohesive the design is (e.g. are "similar" features implemented in similar or different ways). If features are well integrated they may even remove complexity in cases where you would otherwise find limitations strange. Case in point: Methods in Javas anonymous inner classes can only refer to final members from the lexical scope. This is baffling to many Java newcomers. Even if closures with full lexical scope capture may seem an "extra" feature you can also make the argument that it makes the language a better "fit" with fewer surprises. Useerup (talk) 11:25, 15 August 2010 (UTC)

I can see how a red-is-bad and green-is-good mindset may be deceiving. Maybe we could prefix the table with a reference to a (new) section which discusses complexity vs. simplicity? Then there's the pragmatic dimension: Does "average" developers really need to understand C# has built-in (VM supported) marshalling or type-integration features (operator overloading, conversions) or is it ok that only library developers fully appreciate these features? Useerup (talk) 11:25, 15 August 2010 (UTC)

There is a distinct difference between the two languages that, I believe, has a direct bearing on the sizes of the feature sets of the two languages. C# is sold as product, and so has to have new features added every 18 months to make it necessary to buy the next version of Visual Studio. Java is not sold as a product in the same way. The rate of change of the language feature set has many repercussions outside the act of programming. For example, the availability and stability of third-party tools (particularly free/open-source tools). Also, the rate at which skills become out of date in the job market. Spockwithabeard (talk) 19:12, 13 February 2011 (UTC)

Also, when reading through the code examples it seems that they always follow C# conventions (look at method names etc). Kinda clear it was written by someone with C# as their main language. —Preceding unsigned comment added by 85.229.219.4 (talk) 11:49, 15 August 2010 (UTC)

Always? The only example of this I can find is in the section Delegates / method references. Feel free to change the Java example (I wrote it and to tell you the truth I really don't think it is too instructive: It doesn't demonstrate delegates very well and the Java "counterpart" comes across as contrived). Perhaps we should come up with a better example? Anyway, if you think that the conventions used are somehow bias'ed you should consider changing them. However, I fail to see how that is somehow skewing the article. I have written considerable amount of both Java and C# code and if you can point out where you think examples or text can be improved I'm ready to give it at shot. However, I feel that this article i about to outgrow itself and perhaps we should consider splitting up in sub-articles? Useerup (talk) 12:36, 15 August 2010 (UTC)

Possible Fallacy in Feature comparison

I am referencing this section, under the heading "Object Orientation". I believe that Java includes event handling in the majority of it's implementations. All classes implementing java.util.EventListener[1] are able to process events, and all classes extending java.util.EventObject[2] are objects containing the details of the event. These features have been in effect since JDK 1.1 Deltafox1229 (talk) 00:19, 5 December 2010 (UTC)

The problem with this article is that some people have a tendency to put a "Not Supported" for Java for a feature which is supported differently in C# and Java, in the cases where Java and C# does them very differently. I'm not blaming them, because there are no standardized notions of what an object oriented language would have to be. Hervegirod (talk) 13:26, 5 December 2010 (UTC)

No, the problem is that too many people are confused about what exactly is Java. They come here an fail to realize that there is something more basic than what they use every day. Java is both a language and a platform. This distinction is much more clear with C#/.NET because they have different names. You have Java developers who want to turn this into a comparison of IIS versus Tomcat. I kid you not. You can actually use Java without the BCL, as you can use C# without the BCL. It doesn't help that some contributors edit from a biased perspective and fail to properly investigate claims about the language they are biased against. Case in point: The value type discussion above. Useerup (talk) 13:43, 5 December 2010 (UTC)

Java the language has as much event handling as it has properties: Events are modelled in the corresponding framework built upon Java (the language), in much the same way as "properties" are built through methods for getting and setting. Contrast that with C# which has first-class support for event members. You can model an event (observer/observable) pattern in any object oriented language which makes this point rather moot. With you edit it look like the two languages are the same in this respect, which they are not: Java only has an event model in the corresponding BCL and only by convention. C# has a direct event feature based on delegates. This highlights previous discussions as to how much of the BCLs should be included in the comparison. If this article is about the languages, clearly Java does not feature events. If this article is about the languages and *some* of the BCL's, yes then Java does have an implementation of the observer pattern. This is still about the languages (other articles compare the frameworks/BCLs) so, this should be changed to a "no; but an standard implementation of the observable pattern is encouraged through the BCL". That way we can keep this about the languages and still point out that of course you can do event programming with Java. Useerup (talk) 13:31, 5 December 2010 (UTC)

Java has not just event's handling by convention. For example, all AWT and components event's are hard-wired to Java events at a very low level of the JVM / Java library. You do not have to do any specific wiring to use them. It's different for the Observer pattern IMO, because it is just a pattern that you can or not choose to use. Events are there, you can't say in java (or it will be incredibly hard), no I will use another way to handle events that what Java already has. same as for C#. Hervegirod (talk) 13:46, 5 December 2010 (UTC)

AWT is not part of Java. AWT is built upon Java (the language). The hard-wiring you refer to is the AWT components using JNI. That does not make AWT or events part of the Java programming language Useerup (talk) 13:54, 5 December 2010 (UTC)

Ahem you can't have Java without AWT. All widgets events handling is done per AWT, at the core Java platform level. Whether you use AWT or another graphic toolkit. Hervegirod (talk) 15:18, 5 December 2010 (UTC)

Yes I can. I cannot have a GUI application. It is perfectly feaible to do server side app or a command line Java program. Indeed, look at the programming language shootout and several books on algorithms (in Java). Many programs are done without AWT. AWT is not part of the programming language. Useerup (talk) 16:30, 5 December 2010 (UTC)

It would be a strange decision to compare just the keywords of two languages as a feature comparison. If the language designers chose to reserve another keyword, or put it into one of the basic libraries, is an almost arbitrary choice for many features. Maybe what some of you want is a comparative listing of the two sets of reserved keywords, while others want a functional comparison about what it's like to develop software in the two languages. I think the second would be more the interesting article, if both were produced. --Nigelj (talk) 16:03, 5 December 2010 (UTC)

Good points. Dumbing down a programming language comparison to compare keywords would not just be uninteresting but also dishonest. You can certainly compare features without considering the BCLs. I still (like I have said several times over in the discussions above) would welcome a discussion on which parts of the BCLs to incorporate. Dragging in JDO, JPA, LINQ to Entities etc. is taking it too far IMO. Collection classes? yes. Please take part of the discussion on this topic, because we need to do this. Like I said, AWT is *not* part of Java (the language) just as WPF and WinForms are not part of C#. You can certainly do a comparison of AWT/Swing/WPF/WinForms - but not in this article. Useerup (talk) 16:29, 5 December 2010 (UTC)

I must disagree about AWT event handling. You can't do ANY event handling on GUI components in java without using AWT event handling (or it will be VERY hard), because it's hard wired into the language. You can get rid of the AWT components, but not events (and not graphics either). There are two parts of AWT, which people may find confusing: the "core" part, which interface with the native event handling, graphics, and windowing system. And the AWT components. Your WPF and WinForms comparison is valid only for the latter part. Hervegirod (talk) 17:55, 5 December 2010 (UTC)

AWT is not "hard wired" into the language. And you can easily use Java without it altogether (for example, Java on mobile devices - same language, different runtime library). Spockwithabeard (talk) 19:18, 13 February 2011 (UTC)

J2ME Personal Profile contains AWT packages too. Hervegirod (talk) 22:49, 13 February 2011 (UTC)

Java ME MID Profile does not. There is no feature of the Java language or VM (as specified) to support AWT, so it cannot be said to be "hard wired" into the language. The fact that you can't build a GUI without runtime-library support is irrelevant. The Java langauge contains no support for building a GUI. Many Java apps (as stated earlier) have no GUI, such as server and embedded apps. Spockwithabeard (talk) 12:46, 19 February 2011 (UTC)

Java does not have events as a first class feature, and not as a language feature. Period. If you consider java.util then yes, there is a conventional way to implement events. However, AWT has no place in this article. AWT is a framework built using the language, in no way can it be presented as part of the language or even the core library. Events are defined in java.util and if this article should allow "core" libraries then Java+core library can be said to feature events. Useerup (talk) 15:22, 6 December 2010 (UTC)

So, it's just the reserved keywords, then? --Nigelj (talk) 19:55, 6 December 2010 (UTC)

Nice straw-man. Try taking this seriously, please. You can do a comparison of languages which is not just keywords but actual features. Personally I feel that we should take some of the common/base class libraries into consideration, too. But definitely not AWT. What would be next? JSP/JSF/ASP.NET/WCF because you can not do "anything" server-side without those, like you cannot do anything GUI without AWT. Next we have the entire platforms in here and will again be pondering how to split it up. This *is* the language comparison. AWT belongs somwhere else. Useerup (talk) 17:40, 7 December 2010 (UTC)

I think you are under a misconception. Even Microsoft, when comparing how C# and Java do with event handling, do not consider java events as second class citizens[3]. I don't think that you will find a lot of reliable sources explaining that events are second class citizens in Java. However, if you can find those, I'm OK with that. This is not about how we feel it shluld be, for you and of course also for me. Hervegirod (talk) 23:44, 7 December 2010 (UTC)

Could you please try and read my statement again, Hervegirod? You were the one who brought in AWT. My above statement was against including AWT in this article. Note how my statement doesn't say anything about including Java event handling (it is after all not in AWT but in java.util), only about presenting it as a language feature. In C#, event definition and handling is clearly a language feature: The compiler will implement event subscription (adding/removing and combining multicast delegates) for you when you use the event keyword. C# does so at the language level without assuming anything else about events (like signatures, interfaces etc). C# developers can build upon this direct language support to build a specific event model. Building a specific event model involves deciding how/if event arguments are specified, how/if the source is identified, deciding if the subscribers and/or publishers must implement specific interfaces or derive from specific base classes etc. The BCL developers did this in System.* where you'll find the EventArgs class. Note how this latter part is analogous to java.util.* where you find the EventListener interface, EventObject class (akin to .NET EventArgs). Because both languages are object oriented then of course the observer/observable pattern can be implemented. This does not make it a language feature, though. One language (C#) provides standard infrastructure for building any number of event models, all of which will benefit from the language feature - i.e. they will not need to build multicast containers. One such model is found in the System.* namespace. In Java you lack this infrastructure. You can still build any number of event models, but all of them will need to implement multicast containers (subscription lists) specifically for each event exposed by an object. The implementation in java.util (used by AWT) does not solve this, you still need to build event listener collections for all events exposed by all objects. This is a significant and interesting difference between the languages and certainly noteworthy in a comparison article. Now, whether the comparison table should be green or red depends on how much of the BCL we consider ok for inclusion in this article. If this is just the languages (the syntax and the semantics) then Java has a "no; but the BCL offer specific implementation". If we consider the "core" parts of the BCLs ok for inclusion then Java has a "yes; library feature" and C# has a "yes; language feature". The differences I outlines above can then be explained in the associated prosa. Useerup (talk) 07:48, 8 December 2010 (UTC)

Value types (again)

Value types are *not* a C# invention. Even Java has the "primitive" types which has the same semantics. Only Java does not allow developers to specify their own value types, C# does. Value types are not a C# invention, even Pascal and C++ has them. In Pascal they are called "records". C++ has them not as an explicit concept, but any type act as a value type when used as an automatically (stack allocated) variable. So can we please lay this discussion to rest? Useerup (talk) 09:30, 28 November 2010 (UTC)

There is a big difference between C/C++ structures and value types because structures in C or C++ are passed by reference, and they are passed by value in C#. It's the same in Pascal, where records are passed by reference too. Plus there are two kinds of Value types in C#: structures and enumerations. There are enumerations in Java too. Which means that the Value type line is misleading and incorrect. What would be correct would be to have two lines: structures (C# has, Java has not), and enumerations (the two languages have). There is also a specificity in C# because structures are passed by values (contrary to what is done in other languages which have this concept). I have another problem with the table, and most of the article: with almost NO sources, it is 90% OR, even if I agree that a lot of the text may be right. Hervegirod (talk) 14:41, 28 November 2010 (UTC)

I think you may want to read up on C++ and Pascal. If I define a class (or struct) in C++ and declare a local variable of that class, it is *not* a reference; it is an automatic (look it up) object. It is automatically constructed (using a default constructor) and automatically destroyed. It has copy semantics: If I define another variable of the same type and assigns the forst one to it, C++ will "shallow" copy the members from the 1st object to the 2nd (actually, C++ will just copy the memory representation of the object). Also, C++ passes parameters of such type by value, unless you explicitly specify a pointer or reference type. Demonstration:

	class Zem
	{
	public:
		char* question;
		int answer;
	};

	Zem zem1, zem2;
	zem1.question = "The life, universe and everything?";
	zem1.answer = 42;
	zem2 = zem1;
	zem2.question = "What is six times nine?";
	
	std::cout << zem1.question << " " << zem1.answer << std::endl; // outputs "The life, universe and everything? 42"
	std::cout << zem2.question << " " << zem2.answer << std::endl; // outputs "What is six times nine? 42"

As you can see, zem2 is copied from zem1, but their "questions" clearly refer to different objects. If they had been copied by reference there would be only one question. Useerup (talk) 07:49, 29 November 2010 (UTC)

@Hervegirod : "There is a big difference between C/C++ structures and value types because structures in C or C++ are passed by reference" : You're wrong. In C and C++, you can pass a struct by copy:

       // C++ code

       struct Value
       {
          int i;
          double j;
          std::string s;
       } ;

       void foo(Value p_value)
       {
          // p_value is a copy of the original variable
       }

       void bar()
       {
          Value value ;
          foo(value) ;   // value is passed by copy
       }

Fact is, in C++, you can pass whatever you want by copy or reference (my personal preferred curiosity being the reference to a pointer) or even const reference. The "Value Type" semantics exists, too, on C++: Anything pointed to could be considered to not be a value type (a pointed type? ... :-) ...), but all this discussion is blurred by the fact you have references or pointers to a value type, even when allocated on the stack:

       // C++ code

       void foo()
       {
          int i    = 0 ;   // "C# value type"/"Java primitive"
          int j    = i ;   // j is now a copy of i, but a distinct one.
          int & ri = i ;   // ri is an alias/reference to i
          int * pi = &i;   // pi points to i

          i   += 2 ;       // now, ri == 2 (and *pi == 2), but j == 0 [value type semantics]
          ri  += 3 ;       // now, i == 5 (and *pi == 5), but j == 0 [value type semantics]
          *pi += 4 ;       // now, i == 9 (and ri == 9), but j == 0 [value type semantics]
          pi  += 4 ;       // now, pi is invalid [pointer semantics]
       }

In C++, the value type (or concrete type) would be something whose meaningful value you access directly.
Whereas the pointer type would be something to be access indirectly, through pointer dereferencing, but if you play directly with the pointer (i.e. its address value), then lose its meaningful value (and in the example above, you have a bug). So there is a notion of value types vs. pointed types in C++ (which mirrors the difference between value types and reference types in Java/C#).

Paercebal (talk) 15:12, 23 April 2011 (UTC)

I confirm about value types being an important topic. Two examples comparing Java and C# code. Please bear in mind that the point is to use light-weight types (as in: not using the GC or boxing/unboxing as much as possible):

In Java and C#, the "Value Type" is an existing language concept (called primitive in Java).

This can be summed up to: Do you access the data through a reference, or do you access it directly? But despite their similarity, C# Value Types and Java primitives have some important differences:

C# Value Types are C# objects, whereas Java primitives are not Java objects, meaning C# can (and does handle) Value Types both efficiently and genericly, whereas Java cannot handle primitives both efficiently and genericly.

For example, for build-in value/primitive types:

       // Java code

       void foo()
       {
          // testing a build-in primitive
          int i = 42 ;

          // testing Object Oriented properties of a Java primitive
          i.toString() ;              // WON'T COMPILE because int is not an Object
          new Integer(i).toString() ; // will compile, but will be slow: manual boxing involved
   
          // Testing generic containers of java primitives
          Vector<int> array     = new Vector<int>() ;     // WON'T COMPILE !!!
          Vector<Integer> array = new Vector<Integer>() ; // only way to have a vector of ints

          // Testing boxing/unboxing of java primitives
          array.add(i) ;                    // slow: autoboxing involved
          boolean b = array.get(0) == 25 ;  // slow: auto-unboxing involved
          array.get(0) += 5 ;               //WON'T COMPILE !!!
       }

       C# code

       void foo()
       {
          // testing a build-in value type
          int i = 42 ;

          // testing Object Oriented properties of a C# value type
          i.ToString() ;              // fast: no boxing involved

          // Testing generic containers of C# value types
          List<int> array = new List<int>() ;
          array.Add(i) ;              // fast: no boxing involved
          bool b = array[0] == 25 ;   // fast: no unboxing involved
          array[0] += 5 ;             // fast: and now, 1st element of array is 47
       }

The example above shows that C# handle build-in value/primitive types efficiently, and as first class citizens (C# value types have methods, and derive from Object, while Java don't).

The example below will show a Java and C# implementation of an aggregation of data. This data needs to be mutable, needs to used in arrays of millions of those those data, and could be used as keys for Hash tables/maps. Being able to handle those data with value copy semantics is important, too (i.e. the assignment creates a deep copy, not a clone).

So, for those user-defined types supposed to behave like value/primitive types:

// Java code

// Of course, there is no way to have user-defined primitives,
// so will use full Java classes instead

class MyValueTypeSize
{
   public int quantic ;
   public double length ;

   // constructors, methods, etc.
}

class MyValueType
{
   public boolean truthness ;
   // This will need the allocation a separate MyValueTypeSize on the GC heap
   public MyValueTypeSize size ;

   // constructors, methods, etc.
}

   // etc.

   void foo()
   {
      // allocation of one array of contiguous of 1-million references to items
      // (i.e. each item will be allocated separately)
      int size = 1000000;
      MyValueType[] array = new MyValueType[size];

      for(int i = 0; i < size; ++i)
      {
         // for the following line
         // allocation on GC part: 1 for MyValueType and 1 for MyValueTypeSize
         array[i] = new MyValueType(i, 3.1415 * i, (i % 2) == 0);

         // for the following lines
         // to avoid new allocation on GC part, the code must be written
         // very carefully. We choose to write a specific method increment
         // (there are possibly one increment method for each constructor)
         array[i].increment(42); 
         array[i].increment(true, 5.55); 
         array[i].increment(i * 25, 0.05 * i, ((i + 1) % 2) == 0); 
      }
   }

C# code

// testing user-defined value types

struct MyValueTypeSize
{
   public int Quantic ;
   public double Length ;

   // + constructors, operators, etc., as needed
}

struct MyValueType
{
   bool Truthness ;

   // no need for a separate GL allocation for this...
   public MyValueTypeSize Size ;

   // ... so, for all intents, we can consider MyValueType
   // to be an aggregation of an int, a double and a bool
   // in the same structure

   // + constructors, operators, etc., as needed
}

   // etc.

   void foo()
   {
      // allocation of one array (whose size is enough to contain 1-million
      // contiguous items)
      int size = 1000000;
      MyValueType[] array = new MyValueType[size];
				
      for(int i = 0; i < size; ++i)
      {
         // for the following line
         // no allocation on GC part.
         // Everything is modified in the array
         array[i] = new MyValueType(i, 3.1415 * i, (i % 2) == 0);

         // for the following lines
         // no allocation on GC part
         // Note that here is only ONE operator + defined to handle the
         // following lines, instead of one overload for each MyValueType
         // constructor in Java
	 array[i] += new MyValueType(42); 
	 array[i] += new MyValueType(true, 5.55); 
	 array[i] += new MyValueType(i * 25, 0.05 * i, ((i + 1) % 2) == 0); 
      }
   }

And please note that this difference is not mere plain syntactic sugar: There is a major performance cost involved there (allocating millions of small objects is always a problem, both in speed in low-latency cases, and in memory in large data cases).

Paercebal (talk) 15:50, 23 April 2011 (UTC)

Proposal for Deletion

I believe this article should be removed.

First, I believe it is meaningless to try to compare the languages separately from the run-time libraries. Indeed, the article does not, and makes arbitrary choices about whether to include or exclude library features. Both languages are fundamentally useless without at least some library, and are designed to work with library support.

Second, the cited sources are either opinion, or relate only to one language or the other. As such, I believe this article is a synthesis of published material, and therefore contravenes the policy on original research.

Spockwithabeard (talk) 14:39, 19 February 2011 (UTC)

This article has become a kind of forums where C# advocates like to push their own Point of views, I think without even knowing they are doing this. For example, there was a lengthy discussion where people considered that java did not have events, because part of the events framework was provided by the BCL. But the same people have no problem to write that C# has Expression trees or Query language, where it is only a BCL feature. Hervegirod (talk) 14:33, 6 March 2011 (UTC)

BTW, I'm not sure about expression trees, but LINQ querying is definitely a language feature. Rp (talk) 17:12, 16 March 2011 (UTC)

I agree that there is original synthesis going on here. If we are to have an article on this subject, then the sources should limited to reliable publications that explicitly compare C# and Java. I don't think there are many of those - maybe the introductory sections of some books that then go on to describe one language or the other in detail. Of course, if those books are themselves published by Microsoft or Sun (Oracle), then they are hardly neutral. As it stands, this article is mostly a mess of "mine is bigger than yours" bragging by fans, and not much use to ordinary readers. I tried to join in the discussion about events, but just got shouted down, from what I remember. I haven't bothered since, and that's no way to run a WP article. --Nigelj (talk) 16:31, 6 March 2011 (UTC)

To make my point more clear, we need to start from "The developers of Java based it on the C++ programming language, but removed many of the language features that are rarely used or often used poorly."[4] (I can't remember where I first came across that on Sun's old website). What C# seems to have done (although Microsoft won't admit it) is start by directly copying the Java language and concept, then, release by release, adding back in various C++, VB and other random concepts, whether they are or could be used poorly or not. This article repeats, "C# has this; does Java have this? No? Fail." It does this without considering why the feature was left out of Java, what the pros and cons of providing developers with the feature are, or any other relevant issue. Take the first point in the comparison table: "Single-root (unified) type system? Java No; C# Yes". This could be worded, "Explicit language expression of when expensive boxing and unboxing routines have been invoked? Java Yes; C# No". This is what I meant above by '"mine is bigger than yours" bragging by fans', without the depth of coverage that would make the comparison useful to readers. For possible reader types, consider the project manager needing to decide which language to hire developers and develop a solution in, or the school-leaver deciding which language to study in depth to further their programming career. This article is too shallow and too detailed to help either of these. Who is it aimed at? Surely not just the egos of the Wikipedia authors who wrote it?! --Nigelj (talk) 17:21, 6 March 2011 (UTC)

Keep. If the threshold for inclusion in the article is the ability to cite reliable publications that explicitly compare C# and Java, then indeed the entire comparison category (e.g. file systems etc) would have go to away. No, the threshold to meet is that any claims must be verifiable. The language specifications are reliable sources as far as the syntax and semantics goes. Other sources must be used for e.g. history, philosophy. I also do not agree that this is "bragging". Does the article have issues? sure. We should fix them instead of deleting the article. This article is not stale; it still receives edits and it is read by visitors. Clearly keep. But let's fix the problems. Who is it aimed at? As is evident from the discussions above, there is obviously a lot of readers with experience from one language but without understanding of what/how the other is different. As the two languages are overlapping and competing in the marketspace it is and will continue to be a controversial topic; but also an interesting topic. Useerup (talk) 14:57, 9 March 2011 (UTC)

Strong Keep. The constant discussions, sometimes drifting into a flamewar, may be annoying. But this underlines how important the topic is to many people. This article is pretty much about the question why C# was made in the first place, even though it started off so close to Java. Vandroiy (talk) 20:54, 13 March 2011 (UTC)

Strong Keep. I think this is a very useful and informative article that can teach people something about both languages and their differences. There have been many discussions about what form the article should have and what content should be included by it, and there are definitely areas that can be improved, but that doesn't mean we should give up and delete the article. 82.210.112.192 (talk) 19:52, 15 March 2011 (UTC)

Strong Keep. I agree that the article doesn't use a clear method of comparison and that subjective statements are difficult to avoid, especially for contributors who only know one of the languages well. But I don't think this is inherent to the subject. Language features can be clearly separated from library features, and core library features can be distinguished from features in optional libraries. We just need to systematically qualify all statements about features with this information. For instance, statements such as "Java does not support events" or "Java supports events" are inadmissible, because they lack this qualification. Statements must also be qualified with language versions, if the feature in question is version-specific. For instance, "C# has special syntax to support events" is inadmissible. Won't doing this fix most of the problems? Rp (talk) 17:12, 16 March 2011 (UTC)

Weak delete. The article has some value and I don't mind if it stays, but it's impossible to give a realistic comparison of these languages without the corresponding discussion of frameworks and runtimes. Maghnus (talk) 10:53, 23 March 2011 (UTC)

Weak delete. However, I would not mind to keep this article, if only it really compared these two languages. As it is, it has become a feature-fest, not a comparison. I don't think that anybody can have an understanding of how these two languages are similar, and how they differ, by reading this. Only people already knowing Java of C# can really understand anything here. And I'm even not talking about the fact that there are so few references. Hervegirod (talk) 23:48, 24 March 2011 (UTC)

Strong Keep.
I followed both Java and then C# evolution, and this is no accident if there are more "features" in C#. C# evolves faster, whereas Java evolves slowly.
The reason could be justifiable prudence or unjustifiable laziness, or could be the justifiable need to keep it simple or the unjustifiable incapacity to make the language evolve, I don't care.
So the extra features could be useful, or useless, I don't care.
Let the reader decide if delegates, events, unsigned integral types, user-defined value types, operator overloading, etc. are a good thing or not, but don't remove the feature comparison just because you believe the feature is useless in your chosen language.
If you have any doubt about the usefulness of a feature, this Talk page is not the right forum to discuss it: Bring to issue to a developer's forum, http://www.stackoverflow.com for example, and compare the answers from the experts lurking there. Paercebal (talk) 16:10, 23 April 2011 (UTC)

Is this entire article directly lifted from some page at microsoft.com?

Because it looks like it. It reads like an essay and one that seems to be written for Java programmers to switch to C#. Rajakhr (talk) 09:21, 18 May 2010 (UTC)

If you compare two things, and one appears better, you can either:
- Hide your head in the sand, and claim it's a conspiracy
- Add meaningful and truthful arguments that were forgotten
- Accept the apparent better one is the better one.
So please, contribute in a meaningful and truthful way, if possible...
Paercebal (talk) 13:04, 23 April 2011 (UTC)

Besides, the goal of this comparison is not to determine which language or feature is better, but simply to allow programmers to compare possibilities for expressing things in the two languages. Rp (talk) 08:03, 7 June 2011 (UTC)

Edit

I removed the following content:

"Another criticism of checked exceptions is that a new implementation of a method may cause unanticipated checked exceptions to be thrown., which is a contract-breaking change. This can happen in methods implementing an interface that only declares limited exceptions, or when the underlying implementation of a method changes. To allow for such unanticipated exceptions to be thrown, some programmers simply declare the method can throw any type of exception ("throws Exception"), which defeats the purpose of checked exceptions."

This may not happen with checked exceptions. A checked exception must be declared in the public API of the method (throws clause) if you want to throw it. Therefore you may not throw a new type of checked exception unless you intentionally break the API, and this will not happen neither if you are just implementing an interface, nor change the method implementation (as it is not part of the API). --151.75.20.202 (talk) 13:20, 26 May 2011 (UTC)

You could have added un instead of removing the whole section. So your reason for removing it must be something else. I'm not sure whether this discussion should be present. Is discussing the consequences of diffferences between the languages too far beyond the scope of this article? Rp (talk) 21:27, 27 May 2011 (UTC)

Actually criticism in the section is specifically about checked exceptions. There is no contract-breaking change if you throw a different unchecked exception, as you are always allowed to throw any unchecked exception type from within any method, so the section just doesn't make sense if you add un. And, yes, maybe the appropriate place for that is Exception handling#Checked exceptions. --151.75.16.218 (talk) 00:15, 28 May 2011 (UTC)

Platform support

This section is obviously misleading. Mono does not support all the features that we have added in c# column (e.g. functional programming). This table actually says us that C# is multiplatform language but it is not. — Preceding unsigned comment added by 77.37.180.86 (talk) 18:11, 20 June 2011 (UTC)

Functional programming is supported by MS C# or Mono C#. Mono supports C# 4 in full (http://www.mono-project.com/Compatibility). Please remember that this is not a framework comparison, but a comparison of two programming langauges. Functional programming refers to lambdas, closures and the fact that functions are 1st class objects in C# 3+, supported on all platforms. Useerup (talk) 21:56, 23 June 2011 (UTC)

I don't believe you can compare C# to Java without including the framework. Because the framework itself supplements what the language does not support. And what is, and is not moved from the language into the framework is of itself a debated topic.

Lambda Expressions, however, are an extension to the C# language. Just like Macro's are an extension to the C++ language. Neither are the language, even if they are mingled together like they are. 173.167.141.1 (talk) 18:56, 28 July 2011 (UTC)

Lambda expressions are part of the C# language spec. It is not an extension to the language any more than the for loop is. As for including "the framework" please see the discussion on this very topic elsewhere on this page. It is a difficult nut to crack because you are of course right that some language features are complemented or replaced by framework features. But what parts of the framework should then be used as base for the comparison? java.lang? (yes) java.util? (probably yes, some of it), java.awt? (no!). Useerup (talk) 16:02, 30 July 2011 (UTC)

Added Windows Phone to the platforms table.

Java unsigned integer type "char"?

I reverted an edit claiming that the Java char type is an "unsigned 16 bit integer" type. According to the language spec it is an integral type which as soon as it is used with a numeric operator (such as bitwise shift, -and and -or ) it gets promoted to an integer. So the char type is not an integer type, neither formally nor practically. It is a separate integral type which is convertible to integer but is itself not an integer. Please read chapter 5 of the Java Language Specification if in doubt. — Preceding unsigned comment added by 87.50.3.197 (talk) 21:23, 12 June 2011 (UTC)

Setting the ground rules

Rather than speculating what motives we each might have for wanting a certain section (green or red?) included or not, I suggest that we set some ground rules here. It is a complicated issue and there are some gray areas, but with a lot of the topics I think we should be able to come to a consensus.

IMO the overall goal should be a comparison between the two languages as they are experienced by new programmers learning just the language and basic library as they are used across all reasonable disciplines.

Both languages were designed alongside their respective VMs. That a language happens to not have a specific syntactic construct for a given feature, but only a "library" feature does not rule that feature out. Case in point: Java's "soft" references. This is a VM feature which has no specific syntactic representation. It can only be used through a core library. But this feature exists and soft references has semantics different from weak references.

Likewise, some of C# conditional compilation features and assertions - which are clearly language features - do not have specific syntactic constructs. Instead they are used by adorning methods with metadata which is understood by the compiler. While attributes is a language feature, those specific attributes are defined in a library.

Clearly, we cannot draw the line just at the language specification. Significant features would be left out of both languages. To complicate matters, corresponding concepts are sometimes surfaced with syntax elements while the almost exact same feature (clearly present) in the other language has been factored as library feature giving access to the VM feature. Case in point: Synchronization. This was introduced in Java before annotations, hence synchronization is declaratively set with a language keyword. C# had annotations ("attributes") from the start, and chose to surface the almost exact same feature through concrete metadata attributes. Does that mean that C# does not have declarative synchronization? Clearly not! The underlying synch mechanisms of the VMs are just surfaced through different channels.

Because we clearly need to allow some "core" libraries from both languages we need to set some rules for what is in-scope and what is out of scope. In my opinion this article *should not* deteriorate into a comparison of application servers. That is taking it too far.

My initial suggestion is (feel free to suggest changes):

• VM features are in-scope whether they are surfaced through language keywords or syntax or a *core* library
• C# System namespace "contains fundamental classes and base classes that define commonly-used value and reference data types, events and event handlers, interfaces, attributes, and processing exceptions" (quote documentation)
• Java's java.lang "Provides classes that are fundamental to the design of the Java programming language" (quote documentation)
• C# 'System.Collections' and 'System.Collections.Generic' because all developers uses collections and you couldn't imagine a modern language without standard collection types
• Java's collections etc. from java.util.* because all developers uses collections and you couldn't imagine a modern language without standard collection types
• C# System.Linq (but not System.Data.Linq etc) namespace, because LINQ clearly is a language feature and this is where it is surfaced (this is the LINQ to objects stuff and the general LINQ stuff - nothing remotely comparable to Hibernate, JDO or JPA)
• Java's java.lang.annotations - because this is how annotations (clearly a language feature) are surfaced.
• Java's java.lang.ref - weak and soft references which is basic interaction with the GC
• C#'s System.Reflection and System.Reflection.Emit namespaces - reflection is tightly coupled to both languages
• Java's java.lang.reflect package - reflection is tightly coupled to both languages

In-doubt:

• Java's java.math - big integers and decimals
• Java's java.text
• C#'s System.Collections.Concurrent. With .NET4 and task parallelism this is almost a 1st class concept. but...
• C#'s System.Numerics - big integers and complex numbers —Preceding unsigned comment added by Useerup (talk • contribs) 21:23, 10 September 2010 (UTC)

Response

Wikipedia is not original research I'd like to also take point in the fact that this article seems to be talking about a language called "Java". But this language that the article seems to refer to doesn't exist. Indeed, it's part of the requirement of all Java implementations to include certain functionality in their class library. Making a comparison between Java and C# and not including Java's standard library in the comparison is not really comparing Java and C#.

Wikipedia is verifiable It seems interesting that you want to include your own subjectivity into articles by randomly including and excluding namespaces as it suits you. But that's not how Wikipedia works. If you really thing System.Linq is part of C# and not .NET, you need verifiable references. It's not Wikipedia's job to invent language features. Or we can just include the standard class libraries of BOTH languages in this article. Which is a more useful comparison. Jbenjos (talk) 00:21, 12 September 2010 (UTC)

This article is not research. Every fact should be verifiable by an authoritative source, otherwise it doesn't belong here. Do you find any such issues then fix them or report them here. The language specifications are clearly authoritative sources. If a concept (such as query expressions and expression trees) are mentioned in the specification as a language feature then it certainly belongs here. Do you have a problem with that? Why would you want to exclude something which are in the language specification?

Java most certainly exists as a programming language. I believe you may be confused about the relationship between the language, the virtual machine and the standard class library. This is NOT a comparison of the VMs. This is NOT a comparison of the entire stacks (.NET versus Java SE/EE). There are other articles for that. This is a comparison between programming languages. Now, are there perfect demarcation lines between the VM, the language and the BCLs? No, the lines are murky. I gave several examples of that above.

I am aware that a very narrow definition (e.g. only the language specs) could misrepresent one or both of the languages. If a certain feature is part of one of the languages but the designers of the other language opted to put a similar feature into the BCL, then it would not be an accurate representation to say one language has it while the other one doesn't.

However, if you decide that "BCL" means JavaSE) you also include awt, swing etc. These are obviously NOT language features.

My list above was an attempt at a discussion here about where to draw the lines. Instead of wild accusations, perhaps you would care to engage in such a discussion? —Preceding unsigned comment added by Useerup (talk • contribs) 22:01, 12 September 2010 (UTC)

Can you please point to this class library lacking programming language called "Java"? I'm sure Oracle would like to know about it. You CAN NOT call something Java that doesn't pass the Java certification process - which includes a wide implementation of the class library Jbenjos (talk) 00:48, 25 September 2010 (UTC)

Please explain, do you say that there is no such thing as "the Java programming language" because Oracle will not allow a 3rd party to market anything using the Java trademark unless it implements the full JavaSE? —Preceding unsigned comment added by 83.94.199.190 (talk) 17:26, 29 September 2010 (UTC)

The most authoritative source for anything Java language is: Java™ Language Specification, Third Edition, The. By: James Gosling; Bill Joy; Guy Steele; Gilad Bracha. Publisher: Prentice Hall. Print ISBN-10: 0-321-24678-0. Please point us to where in this specification (this is the specification) it says anything about: AWT, Collection classes, application servers, platforms, enterprise etc. What you will find is that it says something about strings, classes, generics and type erasure, blocks and statements, expressions and binary compatibility. Why is it so hard to make a comparison of programming languages just about the languages. If you feel that Java (the ecosystem) or JEE has so many advantages that you absolutely *must* declare them to the world, then please edit the correct article for that. This is not the correct article for comparing enterprise stacks or platform deployments. This article is about programming languages, you know, like C++, C, Python, LISP etc. Useerup (talk) 15:20, 30 September 2010 (UTC)

Response: I think the comparison should be limited to pure computer science concepts, not invented by either sun or microsoft. if you are purely doing a language comparison. Many of features in C#, when opening up my programming languages book are not defined. If there is no universal definition to programming feature , it should be left out, if you are just doing a language comparison. —Preceding unsigned comment added by Bongey (talk • contribs) 20:46, 25 October 2010 (UTC)

Because neither Sun nor Microsoft has or could contribute to the body of knowledge referred to as "computer science"? —Preceding unsigned comment added by 76.23.17.34 (talk) 02:17, 13 February 2011 (UTC)

Another response - drawing the line

There is a wealth of good discussion here, and I hope my humble contribution can advance it. I came here as a long-time C# programmer orienting myself to Java. As such, an article like this is certainly a useful reference (a "keep").

It's pretty obvious that C# is more feature-rich than Java, as a language, for better or for worse. It's hardly biased or even surprising. But note:

• Most of the time, a "feature" in one language is at least something that can be done in the other, or even in C for that matter, in a more roundabout way. But when that's not the case, it is a key point to note.
• Language features are good--if I may say that with neutrality--in that they simplify or streamline something valuable (C# using is a classic example).
• They are bad in that they add complexity to the language itself. If a dozen specialized keywords can be eliminated in favor of one general-purpose solution, the language may be better off. Perhaps the feature-poor Java has a cleaner way of doing something with existing facilities.

The last part, BTW, reminds me of a quote that has stuck with me for years:

"There is only one small problem--modifying the C++ standard is as easy as running for President of the United States. When I mentioned my idea to Bjarne Stroustrup, he looked at me as if I just asked him to lend me a thousand dollars. Then a sudden idea struck me. I can implement strong pointers myself...."

That said, weighing the respective merits of Java's approach versus C#'s is not our task; illuminating the differences is. Readers such as myself are less interested in the which-is-better debate and more interested in understanding how constructs in one language translate most succinctly into the other. To that end, a yes/no feature chart is somewhat useful and a good starting point or summary (the yes, yes lines strike me as a bit silly, though). More useful still is an item-by-item comparison of "this is the C# way" versus "this is the Java way".

Useerup, I agree wholeheartedly with your comments above and elsewhere, if not your detailed list.

We can frame our discussion by asking:

1. What aspects are really part of the language (rather than the libraries or VM)?
2. What is the most useful and natural topic of comparison--strictly the languages, or also some related issues in the libraries and VM?

The second question is important because, if we find it difficult and not worthwhile to draw the fine line between C# and .NET or between the Java language and Java, we should consider adjusting the topic of the article to something more natural and useful. That said, I prefer not to be expansive, as comparing all the other stuff is typically far less valuable than comparing fundamental syntax and capabilities.

Now some specifics:

• To the extent that the language depends on a very small part of the class libraries (e.g. C# int implies Int32, ValueType, and Object), all those dependencies are definitely fair game.
• Features of the VM accessed only through libraries, such as the various shades of weak references, are noteworthy but not really part of the language. I imagine that a novel VM (the next Dalvik, say) might handle things differently without violating the language itself.
• Reflection, of course, is of great interest, but consider this: a VB.NET program can use reflection to inspect compiled code written in C#, though it cannot tell that the source was C#. It's a subtle but real distinction. Reflection is really only indirectly related to the languages via the bytecode.
• Collections, fundamentally important as they are, are just libraries. So what if the .NET BCL doesn't include a priority queue class? You can easily add that class from another library, or write it yourself. In the same vein, so what if Java doesn't have complex numbers? (Contrast with generics, which must necessarily be baked in from the start.)
• LINQ is clearly an important language feature. Particular extension methods (e.g. Any), though they blur the line a bit, are library. Not that it matters, with Java lacking all this.
• Boxing is not exactly a syntactic issue, but it is critical for understanding what you are really telling the program to do (Paercebal talked about this at length elsewhere here). In general, when differences under the hood bleed into the languages, they are worth explaining.
• Again, let me emphasize that library features are worth mentioning by way of contrast or alternative to syntactic features in another language. For example, mentioning C#'s native event-handling features might naturally entail mentioning the EventListener interface on the Java side. I don't want to just see "Java doesn't have this", but rather, briefly, what Java does instead. (The table of course has too little space for details, but the article text will elaborate.)

I see the language as an "inner circle", a core that I will start with to learn the differences between Java and C#. The next bigger circle can include things like weak references and the collection classes. The most gigantic circles can extend to comparing, at a high level, WPF with Swing or whatever. These are all articles I would like to read, but ideally not all mixed together.

I'd like to trim down the feature table a bit. I'm afraid taking out the "yes, yes" items would leave a big column of "no" for Java and "yes" for C#, exacerbating the apparent bias. (If it came to that, it might be better to just have sections "C# features not in Java" and vice versa.) But it may actually be better to replace "yes" and "no" with, let's say,

• native syntax
• library (no, but...)
• none

Not that I will try myself, being so ignorant and biased.

--SlothMcCarty (talk) 05:52, 7 June 2011 (UTC)

I agree with you. The standard way of defining a listener in Java is by using interface EventListener. The standard way of defining a property is by following the JavaBeans specification. etc. And it's pretty obvious that the reason for which the Java language intentionally lacks some specific syntax for these features, is that they can be easily implemented in the class library instead, so that the language can be kept simple. Therefore, I think it definitely makes little sense to talk about the programming language without saying that, in a real-world application, you will typically make use of some BCL class instead of a language-specific keyword. --151.75.53.61 (talk) 03:36, 10 June 2011 (UTC)

SlothMcCarty that is very well put. However, there exists some "core" libraries or types for both languages which could be considered part of the language. Some are even mentioned in the respective language specs. My feeling is that these should be allowed in regardless of specific syntactical support. For instance, the class type of Java and the Type type of C#. As I see it, using the criteria you suggested, we should get rid of the "platforms" table as well as the collections among others. I would suggest a criteria for the rest: Good explanation contrasting the languages should follow each table section. Useerup (talk) 19:01, 14 August 2011 (UTC)

Type system > Enumerations

I am a C# programmer and have been since version 1.0 of the language, but my intimate knowledge of the language may be incomplete. With that said, my understanding of enumerations is that they are type-safe. Also, as far as I know, C# is completely type-safe. It impossible, or near, to do something in C# that is not type-safe.

Enumerations do not derive from integer types (8, 16, 32, or 64-bit), but instead derive from System.Enum which in turn derives from System.ValueType, System.IComparable, System.IFormattable, and System.IConvertible. System.ValueType implicitly derives from System.Object. So, enumerations are value types, but do not derive from any explicit value type. When specifying an integral type for an enumeration, you're merely telling the compiler and runtime what the enumeration's numerical limits are; not deriving from the integral type. The idea of deriving from an integral type is an erroneous one because integral types are value types. Value types are implicitly sealed which means you cannot derive from them.

Enumerations only allow you to assign the enumeration's defined values. Integral values can be assigned to an enumerated type through casting, but this can lead to having values outside the implied range (the defined values) of the enumeration. An exception to this rule is the value of zero, which can be assigned to an enumerated type without casting.

It is true that enumerations don't allow anything other than the enumeration values. But, the Enum class defines four ToString methods which will convert any enumeration to a string without the need to define an explicit ToString method on an enumeration. The Enum class also defines several other methods which makes working with any enumeration easy.

So in short, I propose that the section on Enumerations be revised. I don't know enough about Java to do it in a non-biased manner. — Preceding unsigned comment added by Skoobiedu (talk • contribs) 06:47, 16 July 2011 (UTC)

Thanks Skoobiedu. Good points. You are quite correct and I will try to edit the section (I already edited out the passage which could convey the impression that C# enums are not type-safe). Both languages are indeed completely type-safe, except for when unsafe sections are being used in C#. Useerup (talk) 09:29, 31 July 2011 (UTC)

I think you're missing the point...

Some contributors have hinted at what I'm going to say. Perhaps it should be stated directly.

It's "obvious" that a language with "more" and "better" features is the "superior" language, right? Well, maybe. This article ignores the point that the differences among languages aren't as important as the differences among the programs you write with these languages. For example...

How do Java's seeming "deficiencies" affect one's ability to implement a particular programming approach?
How often do programmers have to "work around" particular features in either language?
How do the languages' features and syntax affect one's ability to write clear, easily maintainted code?

In other words... how do the differences between Java and C# affect their utility as programming tools, including algorithmic "expressiveness"?

I'm sure programmers more-experienced than I will have caught things I've missed. But the article is too low-level; it overlooks the broader issues. WilliamSommerwerck (talk) 20:57, 23 August 2011 (UTC)

(not sure what/who the above comment is aimed at but here goes) No, it is not obvious that a language with more features is "superior" (as you out it). The objective of this article is not to pass judgement on which is superior. You are setting up a straw-man argument. A wikipedia article is about verifiable facts. This article should only under exceptional circumstances label anything as a "deficiency" - and should only do so if there are ample authoritative sources for such a claim. Whether a language supports a specific (or equivalent) feature, or even how it supports a given programming discipline (functional programming, dynamic programs, object oriented programs, numeric or financial applications etc) can be demonstrated by careful examples. However, turning the article into a survey or synthesis of how the languages are actually used would violate WP:NOR. That said, I'm all for creating a more discipline oriented article (as opposed to a feature-oriented article). It is, however, very difficult to do so without introducing original research. Useerup (talk) 17:40, 24 August 2011 (UTC)

I'm concerned that this article contains really a lot of original research, which is maybe inevitable considering the amount of content in it. But I think it has much too many content for its subject. Sticking to valid sources would reduce its content, but improve its quality (and be in line with Wikipedia rules BTW). For now even for programmers its very difficult to read. BTW there is a tendency in this article to explain concepts, but I would prefer to have the explanation in the specific articles about these concepts (example Delegates) rather than in this already overly long comparison article. Hervegirod (talk) 21:41, 28 August 2011 (UTC)

I agree with WilliamSommerwerck. A "feature rich" language tends to be more efficient in some aspects, but it is harder to understand and to maintain. Languages are used to write applications. In more features more treacherous details may hide. For example, comparing signed and unsigned integers may create a serious problem in C/C++. Not having unsigned integers means significant simplification of "rules of the game". In my opinion this is no defficiency, this is GOOD. The article marks not having unsigned integers as Java defficiency, this is ignorance. However, from the point of view C programmer the differences between C# and Java are too small to say which language is "better". Maybe Python ;) --193.165.212.242 (talk) 11:43, 14 November 2011 (UTC) (cs:User:Pteryx)

Suggest correction to "High-Precision Floating Point" row on the feature table

Decimal is a fixed-point type. It's the exact opposite of floating point. The only thing they have in common is that they both can have a decimal point in their string representations. — Preceding unsigned comment added by 66.193.1.106 (talk) 14:15, 7 September 2011 (UTC)

Decimal is a floating-point type. It's modeled as -1^sign * coefficient * 10^-exponent. The exponent term determines where the decimal point will be, hence "floating-point." A fixed-point value is basically an integer with an assumed radix point at a predefined position. SqlDecimal is closer to a fixed-point type, but the scale is still adjustable and it doesn't have the performance benefit that you might expect from a true fixed-point type. Maghnus (talk) 12:51, 15 September 2011 (UTC)