Talk:Comparison of C Sharp and Java
 | Java Start‑class Low‑importance | |||||||||
| ||||||||||
 |
Links from this article with broken #section links : You can remove this template after fixing the problems | FAQ | Report a problem |
| Links from this article which need disambiguation (check | fix): [[CLR]], [[generics]]
For help fixing these links, see Wikipedia:WikiProject Disambiguation/Fixing a page. Added by WildBot | Tags to be removed | FAQ | Report a problem |  |
|
This page has archives. Sections older than 90 days may be auto-archived by Lowercase sigmabot III if there are more than 4. |
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. [1] 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)
- 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)
- 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.
- 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)
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)
- 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.
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)
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)
- "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)
- "Value types" is a kind of language feature.
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)
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)
- (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)
- 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)
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)
- 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)
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#
usingis 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:
- What aspects are really part of the language (rather than the libraries or VM)?
- 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#
intimpliesInt32,ValueType, andObject), 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
EventListenerinterface 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)
Value types (again)
Value types are *not* a C# invention. Even Java has the "primitive" types which has the same semantics. Only Java does not allow developers to specify their own value types, C# does. Value types are not a C# invention, even Pascal and C++ has them. In Pascal they are called "records". C++ has them not as an explicit concept, but any type act as a value type when used as an automatically (stack allocated) variable. So can we please lay this discussion to rest? Useerup (talk) 09:30, 28 November 2010 (UTC)
- There is a big difference between C/C++ structures and value types because structures in C or C++ are passed by reference, and they are passed by value in C#. It's the same in Pascal, where records are passed by reference too. Plus there are two kinds of Value types in C#: structures and enumerations. There are enumerations in Java too. Which means that the Value type line is misleading and incorrect. What would be correct would be to have two lines: structures (C# has, Java has not), and enumerations (the two languages have). There is also a specificity in C# because structures are passed by values (contrary to what is done in other languages which have this concept). I have another problem with the table, and most of the article: with almost NO sources, it is 90% OR, even if I agree that a lot of the text may be right. Hervegirod (talk) 14:41, 28 November 2010 (UTC)
- I think you may want to read up on C++ and Pascal. If I define a class (or struct) in C++ and declare a local variable of that class, it is *not* a reference; it is an automatic (look it up) object. It is automatically constructed (using a default constructor) and automatically destroyed. It has copy semantics: If I define another variable of the same type and assigns the forst one to it, C++ will "shallow" copy the members from the 1st object to the 2nd (actually, C++ will just copy the memory representation of the object). Also, C++ passes parameters of such type by value, unless you explicitly specify a pointer or reference type. Demonstration:
class Zem
{
public:
char* question;
int answer;
};
Zem zem1, zem2;
zem1.question = "The life, universe and everything?";
zem1.answer = 42;
zem2 = zem1;
zem2.question = "What is six times nine?";
std::cout << zem1.question << " " << zem1.answer << std::endl; // outputs "The life, universe and everything? 42"
std::cout << zem2.question << " " << zem2.answer << std::endl; // outputs "What is six times nine? 42"
- As you can see, zem2 is copied from zem1, but their "questions" clearly refer to different objects. If they had been copied by reference there would be only one question. Useerup (talk) 07:49, 29 November 2010 (UTC)
- @Hervegirod : "There is a big difference between C/C++ structures and value types because structures in C or C++ are passed by reference" : You're wrong. In C and C++, you can pass a struct by copy:
// C++ code
struct Value
{
int i;
double j;
std::string s;
} ;
void foo(Value p_value)
{
// p_value is a copy of the original variable
}
void bar()
{
Value value ;
foo(value) ; // value is passed by copy
}
- Fact is, in C++, you can pass whatever you want by copy or reference (my personal preferred curiosity being the reference to a pointer) or even const reference. The "Value Type" semantics exists, too, on C++: Anything pointed to could be considered to not be a value type (a pointed type? ... :-) ...), but all this discussion is blurred by the fact you have references or pointers to a value type, even when allocated on the stack:
// C++ code
void foo()
{
int i = 0 ; // "C# value type"/"Java primitive"
int j = i ; // j is now a copy of i, but a distinct one.
int & ri = i ; // ri is an alias/reference to i
int * pi = &i; // pi points to i
i += 2 ; // now, ri == 2 (and *pi == 2), but j == 0 [value type semantics]
ri += 3 ; // now, i == 5 (and *pi == 5), but j == 0 [value type semantics]
*pi += 4 ; // now, i == 9 (and ri == 9), but j == 0 [value type semantics]
pi += 4 ; // now, pi is invalid [pointer semantics]
}
- In C++, the value type (or concrete type) would be something whose meaningful value you access directly.
Whereas the pointer type would be something to be access indirectly, through pointer dereferencing, but if you play directly with the pointer (i.e. its address value), then lose its meaningful value (and in the example above, you have a bug). So there is a notion of value types vs. pointed types in C++ (which mirrors the difference between value types and reference types in Java/C#).
Paercebal (talk) 15:12, 23 April 2011 (UTC)
- In C++, the value type (or concrete type) would be something whose meaningful value you access directly.
I confirm about value types being an important topic. Two examples comparing Java and C# code. Please bear in mind that the point is to use light-weight types (as in: not using the GC or boxing/unboxing as much as possible):
In Java and C#, the "Value Type" is an existing language concept (called primitive in Java).
This can be summed up to: Do you access the data through a reference, or do you access it directly? But despite their similarity, C# Value Types and Java primitives have some important differences:
C# Value Types are C# objects, whereas Java primitives are not Java objects, meaning C# can (and does handle) Value Types both efficiently and genericly, whereas Java cannot handle primitives both efficiently and genericly.
For example, for build-in value/primitive types:
// Java code
void foo()
{
// testing a build-in primitive
int i = 42 ;
// testing Object Oriented properties of a Java primitive
i.toString() ; // WON'T COMPILE because int is not an Object
new Integer(i).toString() ; // will compile, but will be slow: manual boxing involved
// Testing generic containers of java primitives
Vector<int> array = new Vector<int>() ; // WON'T COMPILE !!!
Vector<Integer> array = new Vector<Integer>() ; // only way to have a vector of ints
// Testing boxing/unboxing of java primitives
array.add(i) ; // slow: autoboxing involved
boolean b = array.get(0) == 25 ; // slow: auto-unboxing involved
array.get(0) += 5 ; //WON'T COMPILE !!!
}
C# code
void foo()
{
// testing a build-in value type
int i = 42 ;
// testing Object Oriented properties of a C# value type
i.ToString() ; // fast: no boxing involved
// Testing generic containers of C# value types
List<int> array = new List<int>() ;
array.Add(i) ; // fast: no boxing involved
bool b = array[0] == 25 ; // fast: no unboxing involved
array[0] += 5 ; // fast: and now, 1st element of array is 47
}
The example above shows that C# handle build-in value/primitive types efficiently, and as first class citizens (C# value types have methods, and derive from Object, while Java don't).
The example below will show a Java and C# implementation of an aggregation of data. This data needs to be mutable, needs to used in arrays of millions of those those data, and could be used as keys for Hash tables/maps. Being able to handle those data with value copy semantics is important, too (i.e. the assignment creates a deep copy, not a clone).
So, for those user-defined types supposed to behave like value/primitive types:
// Java code
// Of course, there is no way to have user-defined primitives,
// so will use full Java classes instead
class MyValueTypeSize
{
public int quantic ;
public double length ;
// constructors, methods, etc.
}
class MyValueType
{
public boolean truthness ;
// This will need the allocation a separate MyValueTypeSize on the GC heap
public MyValueTypeSize size ;
// constructors, methods, etc.
}
// etc.
void foo()
{
// allocation of one array of contiguous of 1-million references to items
// (i.e. each item will be allocated separately)
int size = 1000000;
MyValueType[] array = new MyValueType[size];
for(int i = 0; i < size; ++i)
{
// for the following line
// allocation on GC part: 1 for MyValueType and 1 for MyValueTypeSize
array[i] = new MyValueType(i, 3.1415 * i, (i % 2) == 0);
// for the following lines
// to avoid new allocation on GC part, the code must be written
// very carefully. We choose to write a specific method increment
// (there are possibly one increment method for each constructor)
array[i].increment(42);
array[i].increment(true, 5.55);
array[i].increment(i * 25, 0.05 * i, ((i + 1) % 2) == 0);
}
}
C# code
// testing user-defined value types
struct MyValueTypeSize
{
public int Quantic ;
public double Length ;
// + constructors, operators, etc., as needed
}
struct MyValueType
{
bool Truthness ;
// no need for a separate GL allocation for this...
public MyValueTypeSize Size ;
// ... so, for all intents, we can consider MyValueType
// to be an aggregation of an int, a double and a bool
// in the same structure
// + constructors, operators, etc., as needed
}
// etc.
void foo()
{
// allocation of one array (whose size is enough to contain 1-million
// contiguous items)
int size = 1000000;
MyValueType[] array = new MyValueType[size];
for(int i = 0; i < size; ++i)
{
// for the following line
// no allocation on GC part.
// Everything is modified in the array
array[i] = new MyValueType(i, 3.1415 * i, (i % 2) == 0);
// for the following lines
// no allocation on GC part
// Note that here is only ONE operator + defined to handle the
// following lines, instead of one overload for each MyValueType
// constructor in Java
array[i] += new MyValueType(42);
array[i] += new MyValueType(true, 5.55);
array[i] += new MyValueType(i * 25, 0.05 * i, ((i + 1) % 2) == 0);
}
}
And please note that this difference is not mere plain syntactic sugar: There is a major performance cost involved there (allocating millions of small objects is always a problem, both in speed in low-latency cases, and in memory in large data cases).
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)
- 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)
- 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)
- 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)
- 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 "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)
- J2ME Personal Profile contains AWT packages too. Hervegirod (talk) 22:49, 13 February 2011 (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)
- 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)
- 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)
- 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)
- So, it's just the reserved keywords, then? --Nigelj (talk) 19:55, 6 December 2010 (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)
Proposal for Deletion
I believe this article should be removed.
First, I believe it is meaningless to try to compare the languages separately from the run-time libraries. Indeed, the article does not, and makes arbitrary choices about whether to include or exclude library features. Both languages are fundamentally useless without at least some library, and are designed to work with library support.
Second, the cited sources are either opinion, or relate only to one language or the other. As such, I believe this article is a synthesis of published material, and therefore contravenes the policy on original research.
Spockwithabeard (talk) 14:39, 19 February 2011 (UTC)
- This article has become a kind of forums where C# advocates like to push their own Point of views, I think without even knowing they are doing this. For example, there was a lengthy discussion where people considered that java did not have events, because part of the events framework was provided by the BCL. But the same people have no problem to write that C# has Expression trees or Query language, where it is only a BCL feature. Hervegirod (talk) 14:33, 6 March 2011 (UTC)
- BTW, I'm not sure about expression trees, but LINQ querying is definitely a language feature. Rp (talk) 17:12, 16 March 2011 (UTC)
I agree that there is original synthesis going on here. If we are to have an article on this subject, then the sources should limited to reliable publications that explicitly compare C# and Java. I don't think there are many of those - maybe the introductory sections of some books that then go on to describe one language or the other in detail. Of course, if those books are themselves published by Microsoft or Sun (Oracle), then they are hardly neutral. As it stands, this article is mostly a mess of "mine is bigger than yours" bragging by fans, and not much use to ordinary readers. I tried to join in the discussion about events, but just got shouted down, from what I remember. I haven't bothered since, and that's no way to run a WP article. --Nigelj (talk) 16:31, 6 March 2011 (UTC)
To make my point more clear, we need to start from "The developers of Java based it on the C++ programming language, but removed many of the language features that are rarely used or often used poorly."[4] (I can't remember where I first came across that on Sun's old website). What C# seems to have done (although Microsoft won't admit it) is start by directly copying the Java language and concept, then, release by release, adding back in various C++, VB and other random concepts, whether they are or could be used poorly or not. This article repeats, "C# has this; does Java have this? No? Fail." It does this without considering why the feature was left out of Java, what the pros and cons of providing developers with the feature are, or any other relevant issue. Take the first point in the comparison table: "Single-root (unified) type system? Java No; C# Yes". This could be worded, "Explicit language expression of when expensive boxing and unboxing routines have been invoked? Java Yes; C# No". This is what I meant above by '"mine is bigger than yours" bragging by fans', without the depth of coverage that would make the comparison useful to readers. For possible reader types, consider the project manager needing to decide which language to hire developers and develop a solution in, or the school-leaver deciding which language to study in depth to further their programming career. This article is too shallow and too detailed to help either of these. Who is it aimed at? Surely not just the egos of the Wikipedia authors who wrote it?! --Nigelj (talk) 17:21, 6 March 2011 (UTC)
Keep. If the threshold for inclusion in the article is the ability to cite reliable publications that explicitly compare C# and Java, then indeed the entire comparison category (e.g. file systems etc) would have go to away. No, the threshold to meet is that any claims must be verifiable. The language specifications are reliable sources as far as the syntax and semantics goes. Other sources must be used for e.g. history, philosophy. I also do not agree that this is "bragging". Does the article have issues? sure. We should fix them instead of deleting the article. This article is not stale; it still receives edits and it is read by visitors. Clearly keep. But let's fix the problems. Who is it aimed at? As is evident from the discussions above, there is obviously a lot of readers with experience from one language but without understanding of what/how the other is different. As the two languages are overlapping and competing in the marketspace it is and will continue to be a controversial topic; but also an interesting topic. Useerup (talk) 14:57, 9 March 2011 (UTC)
Strong Keep. The constant discussions, sometimes drifting into a flamewar, may be annoying. But this underlines how important the topic is to many people. This article is pretty much about the question why C# was made in the first place, even though it started off so close to Java. Vandroiy (talk) 20:54, 13 March 2011 (UTC)
Strong Keep. I think this is a very useful and informative article that can teach people something about both languages and their differences. There have been many discussions about what form the article should have and what content should be included by it, and there are definitely areas that can be improved, but that doesn't mean we should give up and delete the article. 82.210.112.192 (talk) 19:52, 15 March 2011 (UTC)
Strong Keep. I agree that the article doesn't use a clear method of comparison and that subjective statements are difficult to avoid, especially for contributors who only know one of the languages well. But I don't think this is inherent to the subject. Language features can be clearly separated from library features, and core library features can be distinguished from features in optional libraries. We just need to systematically qualify all statements about features with this information. For instance, statements such as "Java does not support events" or "Java supports events" are inadmissible, because they lack this qualification. Statements must also be qualified with language versions, if the feature in question is version-specific. For instance, "C# has special syntax to support events" is inadmissible. Won't doing this fix most of the problems? Rp (talk) 17:12, 16 March 2011 (UTC)
Weak delete. The article has some value and I don't mind if it stays, but it's impossible to give a realistic comparison of these languages without the corresponding discussion of frameworks and runtimes. Maghnus (talk) 10:53, 23 March 2011 (UTC)
Weak delete. However, I would not mind to keep this article, if only it really compared these two languages. As it is, it has become a feature-fest, not a comparison. I don't think that anybody can have an understanding of how these two languages are similar, and how they differ, by reading this. Only people already knowing Java of C# can really understand anything here. And I'm even not talking about the fact that there are so few references. Hervegirod (talk) 23:48, 24 March 2011 (UTC)
Strong Keep.
I followed both Java and then C# evolution, and this is no accident if there are more "features" in C#. C# evolves faster, whereas Java evolves slowly.
The reason could be justifiable prudence or unjustifiable laziness, or could be the justifiable need to keep it simple or the unjustifiable incapacity to make the language evolve, I don't care.
So the extra features could be useful, or useless, I don't care.
Let the reader decide if delegates, events, unsigned integral types, user-defined value types, operator overloading, etc. are a good thing or not, but don't remove the feature comparison just because you believe the feature is useless in your chosen language.
If you have any doubt about the usefulness of a feature, this Talk page is not the right forum to discuss it: Bring to issue to a developer's forum, http://www.stackoverflow.com for example, and compare the answers from the experts lurking there.
Paercebal (talk) 16:10, 23 April 2011 (UTC)
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)
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.
- ^ "Java Language Specification"". "14.21 Unreachable Statements".
{{cite web}}: CS1 maint: ___location (link)