Talk:Comparison of C Sharp and Java/Archive 3

Archive 1

Archive 2

Archive 3

Proposal for Deletion

I believe this article should be removed.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Edit

I removed the following content:

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

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

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

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

Platform support

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

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

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

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

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

Added Windows Phone to the platforms table.

Java unsigned integer type "char"?

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

Setting the ground rules

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

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

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

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

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

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

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

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

In-doubt:

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

Response

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

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

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

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

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

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

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

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

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

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

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

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

Another response - drawing the line

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

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

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

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

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

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

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

We can frame our discussion by asking:

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

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

Now some specifics:

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

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

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

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

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

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

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

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

Type system > Enumerations

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

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

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

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

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

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

I think you're missing the point...

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

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

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

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

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

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

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

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

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

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

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

Value types

C# value types are not syntactic sugar. To meet that definition you would have to demonstrate what kind of code is really generated which you could have written yourself. You cannot do that with value types as they exhibit copy semantics - i.e. they are stack allocated and new copies are created when assigned or passed as parameters. Apart from that, being "syntactic sugar" is not an impeachment. Every single programming language is rife with "syntactic sugar". For loops are syntactic sugar: You can demonstrate how the resulting code can be generated as a result of statements and a while loop (or vice versa). Syntax matters. Useerup (talk) 22:26, 25 October 2010 (UTC)

Response: Value types are not a language feature,end of story, your wrong , give it up. Nobody outside Redmond and MS Fanboys cares about value types. They are not defined in any computer science literature, they are an invented type by MS. Not once in programming in C/C++/python/ruby/java/ADA/perl have I ever heard someone say 'geez wiz I wish I had value types'. You really need to stop arguing with everyone on this page. You keep reverting peoples changes, pretty much disagreeing with everyone where they are saying there is bias. How are we suppose to get rid of bias if you are allowing any real changes? —Preceding unsigned comment added by Bongey (talk • contribs) 14:46, 26 October 2010 (UTC)

C#/MS aren't the first once that use the naming 'value' and 'reference' types for their objects, let me just name ECMAScript (or more commonly known as javascript), which was there long before, and used that including the name. Before you make assumptions, here's a technical (though easy to understand) explanation of what a value type actually is: http://stackoverflow.com/questions/1113819/c-arrays-heap-and-stack-and-value-types/1114152#1114152. Try to link that to C++ and you'll see that a reference type is actually nothing but a pointer to an object (which is stored on the heap) that is stored on the stack, and with value types, the actual object is stored on the stack. So under different names, this feature is present in a lot of programming languages. Aidiakapi (talk) 10:02, 15 September 2011 (UTC)

"Value types" is a kind of language feature.

In Java, they are called primitives.
In C++, the difference can be summed as "Do I own the object directly, or through a (smart of not) pointer?". The difference is very important, as in C++, the last thing you want is to allocate everything through a new, if only because of performance reasons. But I should not have to explain you this, as you claim extensive experience in C++.

Anyway, this is exactly the reason why in Java primitives are not objects (I was told they tried having all primitives being true objects at first, but turned back because of performance).
In C#, they made Value Types derived from Object, but still made them "primitives" as understood by Java.

So Value Types are, as primitives, a language feature.

Fact is, Value Types as understood by C# are a first-class citizen of C#, when their equivalent (primitives) are not in Java:
C# handles boxing/unboxing when needed, and does not impose boxing/unboxing when it is not needed, for example.
Java is unable to handle primitives correctly without always boxing them first (for example, in generics).

Thus, the difference in handling Value types/primitives by the two languages is very important, and should be explicit in the current article.
Paercebal (talk) 13:05, 23 April 2011 (UTC)

I fail to see what's specific in Value Types, except Microsoft's marketing maybe. In .NET value types are also boxed / unboxed, because .NET really wraps the primitive values in Objects, and this operation cost a lot, like in Java. Also transparent boxing / unboxing of primitives is also managed in Java, for example this is perfectly valid Java code:

List<Integer> list = new ArrayList();
list.add(2);
int value = list.get(0);

More than that, if you try to code the same examples provided by Microsoft to explain how Value Types are working, these examples also work in Java, with an almost identical syntax.Hervegirod (talk) 21:41, 24 June 2011 (UTC)

You are mistaken, value types are not boxed/unboxed in .NET like they are in Java. This would be the code in C#:

var list = new List<int>();
list.Add(2);
int value = list[0];

And it would not involve the relatively expensive boxing and unboxing conversions. This goes for any primitive and value type (primitive types are just a subset of value types). int is a value type, and in C# you can define new value types. Only when value types are treated like objects (reference types) are they boxed. You may declare arrays of custom value types and the array will contain the actual values not a boxed references to values. Useerup (talk) 23:23, 26 June 2011 (UTC)

Microsoft documentation says: "Boxing operations occur when you pass a value type to a method that takes a System.Object as an input parameter."[2]. Which is the case for List.[3]. There is a lot of syntactic sugar in C#. Hervegirod (talk) 12:39, 15 January 2012 (UTC)

This thread is more than six months old, so I wouldn't expect much response. However, the documentation you linked says "..takes a System.Object as..". Generic list does not take System.Object as input parameter, indeed, the lack of boxing is one the main reasons for generics to exist and why generic collections are faster than their nongeneric counterparts. List<T> differs from ArrayList (which inherits from IList interface) by strong typing of the collection objects. --Sander Säde 12:59, 15 January 2012 (UTC)

As Sander Säde says, you are linking to the non-generic version (comparable to a "raw" type in java). C# has generic versions of collections and in there you will find a List<T> as was demonstrated to you in the example above. Repeat: Value types are first-class citizens and unlike in Java no boxing is performed when stored in a generic collection of the same type. It has to do with the fact that C# has reified generics and does not erase the type of generics parameters.--Useerup (talk) 16:52, 16 January 2012 (UTC)

Trying to implement a Complex type in C# is a good exemple of what C# can do with value types and operator overloading (kind of new primitive types). It is impossible in Java. — Preceding unsigned comment added by 193.8.222.12 (talk) 10:53, 17 January 2012 (UTC)

Incorrect/Outdate Comparison Chart

It seems that the comparison chart has some mistakes or it's outdated, it needs a java expert to revise it. I think java has some features but in the article it's said it doesn't such as : Implicit conversions,Explicit conversions, Events, Rectangular (multidimensional) arrays, Unified arrays and collections, ...

Also it seems that features of C# is listed, then it compared to java, which is a completely wrong approach since in many cases java has a better and more smart workaround for a problem without needing to have a feature for it. For example java never needs Explicit interface implementation, since it has co-variant return types. — Preceding unsigned comment added by 83.166.30.230 (talk) 17:19, 14 December 2011 (UTC)

The purpose of explicit interface implementation in C# is to hide functionality unless an instance is explicitly casted to the interface type, or to stack method or operator implementation that would otherwise clash (such as IList vs. IList<T> member implementation). So co-variant return types in Java is not equivalent. Dahvyd (talk) 06:28, 15 January 2012 (UTC)

The table is correct:

• Implicit/explicit conversions: Perhaps they should be termed custom implicit and explicit conversions. Java does not allow you to create a new type (class) and define conversions to be used automatically when resolving parameter types (implicit conversions) or custom "casting" logic (explicit conversions). In C# implicit conversions have been used to allow automatic "promotion" from e.g. int to the decimal.
• Events in Java exist in the BCL, but it is not a language feature as it is in C# (this WP article is about the programming languages). C# events generate "adders" and "removers" automatically much like automatic properties.
• Rectangular arrays: No, Java does definitively not have those. Both Java and C# have "arrays of arrays" (also called "jagged" arrays), but only C# has rectangular arrays. Their usefulness can be discussed; they have certain advantages (sometimes better performances under random access) and drawbacks (overhead under sequential access) compared to arrays of arrays.
• Unified arrays/collections: C# allows a "list" view on arrays and the "foreach" loop uses the unified IEnumerable interface which both arrays and collections implement. In Java, arrays and collections have not been unified; rather the "for" loop has been extended to accept both collections and arrays with the "for each" syntax. But they are actually different statements and you cannot pass an array where a list is expected. You can in C#

Maybe the table needs to be supported by more examples? --Useerup (talk) 16:46, 16 January 2012 (UTC)

Tooo looong... to navigate... comfortably...

Hi all,

When I read this article, I found that I had to skip several sections in order to reach the stuff I was looking for. I got suspicious and downloaded the source code—a whopping 103 KB of plain text! What's worse, it's got several problems like neutrality, original research... and the first section is huge!

Does anyone have any ideas as to how to improve this article? I already added the {{Multiple issues}} template to replace the others. But tinkering with templates does not improve an article.

Thanks,

The Doctahedron, 02:33, 24 January 2012 (UTC)

Split the "feature" table into multiple tables and move them to sections with the text/samples. This will allow them to appear more as section summaries than a single monolith? Cropping some details? --Useerup (talk) 21:11, 25 January 2012 (UTC)

Personally, I'd make the tables sortable and collapsible. I'd also put some tables into subpages. Any suggestions on how to do that? 68.173.113.106 (talk) 19:18, 23 February 2012 (UTC)

String interning

Hello all - I think this article would benefit from a discussion on string interning and how the respective platforms deal with that. Any thoughts? — Preceding unsigned comment added by 57.66.102.70 (talk) 15:08, 17 February 2012 (UTC)

What's that? 68.173.113.106 (talk) 19:15, 23 February 2012 (UTC)

Unified type system

C# (and .NET Framework) has no unified type system. I.e. pointers and interfaces does not derive from the System.Object. Moreover, C# does not allow pointers to be encapsulated as objects.

194.54.20.58 (talk) 12:12, 1 March 2012 (UTC)

See http://msdn.microsoft.com/en-us/library/aa664638(v=VS.71).aspx Useerup (talk) 17:28, 1 March 2012 (UTC)

Did you bother to try run that code using pointers? Try to compile this:

class Test
{
  unsafe static void Main()
  {
    int i = 42;
    int* p = &i;
    Console.WriteLine(p.ToString()); // Operator '.' cannot be applied to operand of type 'int*'
    new Stack<int*>().Push(p); //The type 'int*' may not be used as a type argument
    new Stack().Push(p); //Argument 1: cannot convert from 'int*' to 'object'
  }
}

See http://msdn.microsoft.com/en-us/library/y31yhkeb(VS.90).aspx “Pointer types do not inherit from object and no conversions exist between pointer types and object. Also, boxing and unboxing do not support pointers.” 194.54.20.58 (talk) 06:18, 2 March 2012 (UTC)

Find a reliable source which says "no, C# does not have a unified type system". So far there are only sources supporting that C# has a unified type system. You are correct that the native-oriented type "pointer" does not derive from object. But the pointer type is not part of the common type system of C#. It is a type to which you only gain access when you run the extended version of the language which you get access to by compiling with the unsafe option. But it is really down to reliable sources. Remember, Wikipedia is about verifiability. --Useerup (talk) 07:07, 2 March 2012 (UTC)

I found http://msdn.microsoft.com/en-us/library/2hf02550(VS.71).aspx which says that the common type system supports value types and reference types. Reference types can be self-describing types, pointer types, or interface types. So pointers ARE a part of CTS. And pointers are just pointing to an object, they are not objects itself, they are simply an address of an object.

Anyway, if you are concerned using unsafe context, try to compile this: Console.WriteLine((object)default(TypedReference));

.NET Framework has exceptions from its rules, and these exceptions makes statement “Every type is deriving from/can be converted to object.” false. If Microsoft wrote “All types derive from the System.Object base type.” it should also write ”except pointers.” but it didn’t on that page (it did on other, the link is in my previous post). 194.54.20.58 (talk) 07:47, 2 March 2012 (UTC)

Unsigned integer types

I changed the entry for unsigned integer types. Java's char type is an unsigned 16 bit integer. I'm tired of reading that Java doesn't have any unsigned integers at all. It's clearly not true, although the number of unsigned integer types is very limited. The "simple/primitive types" section should probably also be changed. — Preceding unsigned comment added by 86.52.7.203 (talk) 12:02, 2 May 2012 (UTC)

Simplicity vs. feature richness

Wikipedia is great for beeing _SIMPLE_ not for beeing "feature rich". This article evaluates C# as better, because it has more features, than Java. The "missing" features of Java are marked red. Diplomatically speaking, this approach is not very clever. 193.165.212.242 (talk) 11:54, 14 November 2011 (UTC) (cs:User:Pteryx)

The tone of the article makes it seem heavily biased towards C# because it has features that Java doesn't - ignoring whether Java would actually benefit from these features or not, and the fact that the vast majority of them were deliberately left out because of design principles of the language. Then lo and behold when a feature comes along that's in Java and NOT in C# (checked exceptions for instance) the article launches straight into talking about all the disadvantages of checked exceptions! And when the opposite happens, such as with LINQ, the article discusses all the positives about it.

This article has the potential to be good, however at the moment it's nothing more than a load of biased waffle. I use both C# and Java extensively and have no bias towards one or the other, but this page definitely does. 86.26.141.146 (talk) 17:31, 1 January 2012 (UTC)

Once again (see below): this article compares two languages by listing their features and mentioning alternatives on the other side. Because C# has more features than Java, C# comes out as ... well, having more features. There is no bias in that whatsoever. Commenters like you keep coming here on how the article is 'biased towards' C#. I don't see any such bias. Please point it out. There definitely needs to be an opinion piece to explain to people using software that more features doesn't always equate better, but this article is not the place for that, I think. Rp (talk) 18:05, 3 January 2012 (UTC)

Article.isBiased() == false; C# is simply a newer language than Java and thus has more features, because the C# programmers thought of stuff that the Java guys didn't. But that doesn't make it better. How it's used is important as well. Cheers, The Doctahedron, 00:42, 24 January 2012 (UTC)

I use both Java and C#. I prefer C# solely for its support of events. Now I've seen events in old Pascal code, so they aren't exactly a new concept - I know that this is just one example of a feature that Java is missing, but is it really that biased to point it out? After all, C# support on mobile phones is inexistent in most cases, and poor on Android - is there any free C# compiler for Android? This "missing feature" for C# is also pointed out in the article, along with arbitrary-length floats. Yes, Java has a lot of red boxes in that list, but that doesn't mean that the list is biased - just that Java has less features than C#. We could compare C# and Java to x86 assembly, and assembly would be almost a solid pane of red boxes - but this doesn't mean that it is worse or inferior, just that it is intended for a different purpose. 90.194.203.69 (talk) 12:39, 16 February 2012 (UTC)

My understanding was that this is supposed to be a discussion about the semantics of the language, and that the underlying platforms were compared elsewhere. C# has language-level support for a lot of things Java doesn't, so a feature-comparison (an objective way to compare the two) will intrinsically favor C#. — Preceding unsigned comment added by 152.23.122.74 (talk) 20:59, 2 May 2012 (UTC)

I used both C# and Java after a long time with C++. I think the debiasing of the article should be done by explaining the differences of the two languages, not only enlisting them, which has been done at some places where it is written that delegates, for instance, have been deliberately left out. Like in this example, if Java is "missing" some features because it is older, this should be clearified and referenced. If a feature has been deliberately left, again, a referenced information is needed. And I propose to use a four-colour scheme so that deliberately left out features are marked with a colour different than green, yellow, or red.

I think this discussion here shows that the article seems to be biased, but actually lacks referenced clarifications. As I used Java around two years and C# less than a year in projects, I think others with more experience would be more appropriate for the job of adding the missing information. To the experts: Please, please do not forget that you are writing for an encyclopedia. I plead to the prophets of both languages to add facts, if they are interested to add anything, and not a list of dogmas. Sae1962 (talk) 10:25, 3 September 2012 (UTC)

I think that the article is no more biased. I plead to remove the marking that it is biased. Sae1962 (talk) 15:06, 12 September 2012 (UTC)

Be bold, go ahead and remove it. I do think the article still has other issues, though. Mostly structural, but there is also the pesky problem of agreeing on where the language stops and the framework begins. Useerup (talk) 19:19, 12 September 2012 (UTC)

Please PR this page

Please Peer Review this page. Thanks! 68.173.113.106 (talk) 01:13, 10 March 2012 (UTC)