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.wikipedia.org/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.wikipedia.org/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)