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)