This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 |
I tidied up these sections as there was some glaring misconceptions (delegates, events, closures and observer pattern were all lumped together) and some NPOV issues ("plain, old object-oriented design"). —Preceding unsigned comment added by Useerup ( talk • contribs) 04:54, 18 May 2010 (UTC)
Any idea what was intended when someone wrote:
In Java Operator Overloading is performed by language itself only Like '+' Operator. (String + any other object = String) and (int + int = int). but this facilities can not provide to our application. ( By- Bhanu Pratap Singh )
Makes little sense to me - hardly operator overloading at all. Removing. Amniarix ( talk) 19:43, 1 July 2009 (UTC)
In this article everybody is mixing up the runtime environment (JRE <-> .NET Framework) with language features. I think this is an error. Thomas Maierhofer ( talk) 12:47, 20 January 2009 (UTC)
Why does the data types chart say "No" for C# for "Big decimal (financial) type", and then provide a cite link to an article on the big decimal/financial data type "decimal" in the C# online reference? —Preceding unsigned comment added by Cerowyn ( talk • contribs) 18:04, 8 February 2010 (UTC) Big Decimal is a particular type of Arbitrary-precision arithmetic, which is supported in Java, Ruby or Python, but not in C#, which "only" has a decimal type defined with 128 bits maximum. Hervegirod ( talk) 21:43, 8 February 2010 (UTC)
I have started incorporating the "notations and special features" into the main body of the text while trying to preserve the examples. I started with "yield" and generator methods. This statement: "in C#, both the generic and non-generic versions must be implemented at the same time, adding length to the code" is false. I have removed it. If anyone can come up with a reference to such a requirement, please cite. Useerup ( talk) 08:20, 9 June 2010 (UTC) I also removed the reference to "Project Lombok". Lombok is 1) not a language, VM or library feature, 2) not from a 1st party (Sun/Oracle), 3) relying on brittle byte-code manipulation which is not compatible with all VMs and have known incompatibilities with IDEs. It does not belong here. Useerup ( talk) 09:05, 9 June 2010 (UTC)
The Operating Systems chart gives C# a "no" for Mac OS/X and the assorted flavors of Linux, and yet we have the Mono project mentioned just a few lines above. Did the author of the article forget to read Wikipedia's Mono article or the Mono web site? —Preceding unsigned comment added by 129.176.151.10 ( talk) 18:11, 17 June 2010 (UTC)
Why the "language only" restriction? In a article between C# and Java, a comparison of "language features" without their respected platforms is totally pointless and misleading. Virtually everyone who uses Java uses the standard libraries and likewise for C# (.NET). You realistically can not make a useful comparison between the languages without understanding the platforms. For instance: this article lists C# as "green" for Linux, despite Mono implementing a fraction of .NET proper.
I also question why suddenly now it was decided to remove the Collections comparison from the table. It was there for over a year. I think this clearly points to the bias in this article: before I added some collections Java has that .NET does not, no one seemed to care about this table. Why suddenly so much caring? Java's Collection Framework is actually quite good and well designed, somewhere where Java might have more "green" then C#. Oops! But when I did this (wrote in Collections that Java has that .NET doesn't, the whole table mas mysteriously removed. Suddenly it was "not relevant", I suppose.
Obviously having anything that would convey some sort of advantage to Java in a Java vs C# comparison would be a tragedy and must be removed with prejudice. Jbenjos ( talk) 23:15, 9 September 2010 (UTC)
I just removed the second sentence in this:
"In addition to this, C# can help mathematic applications with the checked and unchecked operators that allow to enable or disable run-time checking for arithmetic overflow for a region of code. It also offers rectangular arrays, that have advantages over regular nested arrays for certain applications.[18]"
This isn't true. C# provides a custom rectangular (or multidimensional) array syntax like this: "new Scalar[width, height]". However, that is basically functionally identical to what is commonly done in C++, Java, and C#: "new Scalar[width * height]". Also, the referenced .pdf paper was saying that most languages (such as Java which was mentioned) only have rectangular arrays and don't have direct language-level support for "block, symmetric, or sparse" arrays. I believe the author would consider Java to have rectangular arrays and that directly contradicts the rectangular array advantage for numeric applications mentioned in the Wikipedia entry.
Ramses89 ( talk) 19:04, 28 September 2010 (UTC)
To whoever made the edits claiming that C# does run-time type checking: I have reverted your edits because you are wrong. Java needs to put in type checks to be performed at runtime because of Javas type erasure. These checks are inserted into the code calling the methods of the generic. There is only one type in Java for each generic type: The raw type. C# generics are reified: There will be multiple "closed" type; one for each unique realization of the generic. The types methods and implementations are verified as type safe and need no extra type checks put into the calling ("client") code. Now, if you find the explanation in the article confusing let us discuss how to clarify. But please don't remove verifiable facts. Useerup ( talk) 20:48, 7 October 2010 (UTC)
The C# code in the article is highlighted (but not Jave code) to give it a "nicer" feel. —Preceding unsigned comment added by 14.96.184.114 ( talk) 22:49, 9 October 2010 (UTC)
The fundamental POV issue I see with this article is it seems to give the impression that C# is a better language then Java. How it accomplishes this is through a subjective idea of what is valid information in this article. I've tried to improve the neutrality of this article by spending a non-trivial amount of my own time adding things I believe are strengths of Java in comparison to .NET. However, more active editor(s) seem to be picking and choosing what features constitute "language features" and what features constitute "runtime features" within the context of this article, and quickly reverting any attempts I have made to make this article seem more balanced to the reader. These users will remove entire sections which they consider "runtime" features and reinstate others which in their opinion constitute "language features".
The problem at a fundamental level is not so much the separation of language and runtime for the purposes of comparison - it is that this kind of separation is not useful for a principled comparison. To make a analogy, it's like trying to useful comparison to car models based upon one or two of their major features, while picking this those features to promote a specific agenda in the comparison. You simply can not do this and remain neutral.
Even more concerning is that both C# and Java both rely on their respected runtime and standard libraries to derive language features! Separating runtime and language is an artificial separation, that's not entirely even possible. This is without regards to the fact that C# and Java programmers will be working with the respected standard libraries at such a deep level, such that ignoring their existence does not produce a realistic worldview of language capability.
Worse, this article gives the reader a incorrect perception about language comparison in general: that language features should be looked as a separate entity not alongside all the other capabilities of framework and tooling. Truth of the matter is, these things are as important if not more important then what is basically the built in syntactical macros of a language.
If you compare Java and .NET in the holistic manner, I am confident it is possible to create an article that is NPOV and truly shows the strengths and weaknesses of each camp with respect to each other. This article as it is, doesn't accomplish it. But it is certainly possible. Jbenjos ( talk) 17:23, 17 October 2010 (UTC)
I have just given a very careful reading to the 'introduction' section. In the process, I promoted it to being the
WP:LEDE (there wasn't one) and simplified some of the duplication I found (
). It seems to me after that process that what the introduction was trying to say, even before I altered it, was that this is a parent article, and that
Comparison of the Java and .NET platforms is a child article, per
WP:SPINOUT. This makes perfect sense: if I was a young student trying to decide which of these languages to learn, or a system architect deciding which to employ in a new development, or a chief executive deciding which to specialise the whole business upon, then this is the article I would expect to start at - the one with the most general name. This should cover all the relevant bases, in SPINOUT style, with links to more detailed articles about the platforms, the platform extensions (like Java EE, NANT, what-have-you), the developer bases, the support networks, the libraries, the licences, the benchmarks, the runtimes, scalability, everything. Two things we should not say here are (1) this is only about the curly braces and the while
loop syntax; (2) This article is nearly finished. --
Nigelj (
talk) 12:18, 18 October 2010 (UTC)
I tried finding something about tuples and C# on Google, but it just seems as if it's a normal object with two generic arguments? Doesn't Java have that as well? —Preceding unsigned comment added by 85.229.222.130 ( talk) 16:16, 23 October 2010 (UTC)
Recently the platform support was edited to show "partial" for C# on a number of platforms because the latest version of C# "wasn't even available" on those platforms. That was correct. Mono C# 4.0 has now been released for a number of platforms and I edited the platforms covered by Mono.
This was promptly reverted with a reference to "C# support on non Windows platforms is partial, because Mono does not support all of .NET framework (WPF, etc...))". I am sorry, but this article is still about C# and Java (the language) and not the .NET Framework or JRE. Developers developing games for iOS are very much programming in C# - but need not use the .NET Framework. Please help keep this article about the languages and take the library comparisons to comparison of .NET and Java. Thanks. Useerup ( talk) 00:52, 25 October 2010 (UTC)
for
loop have been extended to accept an interface for iterating through collections, so the for
loop has a dependency to the iterable interfaces as well which brings it preciously close to collections. IMO collections should not be here though. Similarly with platforms: They were initially introduced demonstrating that Java existed on a number of platforms where C# did not. But how does a programming language support a platform? If there exists a cross-compiler, certainly a developer can use the language to develop for that platform. Like Android. But then the entire platforms section becomes moot. IMO that comparison belongs in the comparison of the .NET and Java platforms where it can be properly qualified. In this context it just doesn't make sense.
Useerup (
talk) 22:09, 25 October 2010 (UTC)
Java does not support operators with these types. You cannot use the + or * operators, you have to use the member functions instead. This is an important difference between Javas types and the C# ones. Useerup ( talk) 09:30, 28 November 2010 (UTC)
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)
http://www.mono-project.com/Compatibility GeirGrusom ( talk) 12:01, 26 February 2011 (UTC)
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)
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)
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)
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)
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.
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.
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.
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)
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.
Seems to me that there are plenty of significant differences, right? Useerup ( talk) 23:38, 21 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: 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
You cannot say something is OO and miss basic features of being OO see
http://en.wikipedia.org/wiki/Object-oriented_programming.
Please don't undo the dispute in the section until this is resolved.
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)
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 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)
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)
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"
// 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
}
// 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]
}
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 = array0 == 25 ; // fast: no unboxing involved
array0 += 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 MyValueTypesize;
for(int i = 0; i < size; ++i)
{
// for the following line
// allocation on GC part: 1 for MyValueType and 1 for MyValueTypeSize
arrayi = 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)
arrayi.increment(42);
arrayi.increment(true, 5.55);
arrayi.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 MyValueTypesize];
for(int i = 0; i < size; ++i)
{
// for the following line
// no allocation on GC part.
// Everything is modified in the array
arrayi = 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
arrayi += new MyValueType(42);
arrayi += new MyValueType(true, 5.55);
arrayi += new MyValueType(i * 25, 0.05 * i, ((i + 1) % 2) == 0);
}
}
And please note that this difference is not mere plain syntactic sugar: There is a major performance cost involved there (allocating millions of small objects is always a problem, both in speed in low-latency cases, and in memory in large data cases).
Paercebal ( talk) 15:50, 23 April 2011 (UTC)
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)
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)
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)
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)
This section is obviously misleading. Mono does not support all the features that we have added in c# column (e.g. functional programming). This table actually says us that C# is multiplatform language but it is not. — Preceding unsigned comment added by 77.37.180.86 ( talk) 18:11, 20 June 2011 (UTC)
Functional programming is supported by MS C# or Mono C#. Mono supports C# 4 in full ( http://www.mono-project.com/Compatibility). Please remember that this is not a framework comparison, but a comparison of two programming langauges. Functional programming refers to lambdas, closures and the fact that functions are 1st class objects in C# 3+, supported on all platforms. Useerup ( talk) 21:56, 23 June 2011 (UTC)
I don't believe you can compare C# to Java without including the framework. Because the framework itself supplements what the language does not support. And what is, and is not moved from the language into the framework is of itself a debated topic.
Lambda Expressions, however, are an extension to the C# language. Just like Macro's are an extension to the C++ language. Neither are the language, even if they are mingled together like they are. 173.167.141.1 ( talk) 18:56, 28 July 2011 (UTC)
Lambda expressions are part of the C# language spec. It is not an extension to the language any more than the for loop is. As for including "the framework" please see the discussion on this very topic elsewhere on this page. It is a difficult nut to crack because you are of course right that some language features are complemented or replaced by framework features. But what parts of the framework should then be used as base for the comparison? java.lang? (yes) java.util? (probably yes, some of it), java.awt? (no!). Useerup ( talk) 16:02, 30 July 2011 (UTC)
Added Windows Phone to the platforms table.
I reverted an edit claiming that the Java char
type is an "unsigned 16 bit integer" type. According to the language spec it is an integral type which as soon as it is used with a numeric operator (such as bitwise shift, -and and -or ) it gets promoted to an integer. So the char
type is not an integer type, neither formally nor practically. It is a separate integral type which is convertible to integer but is itself not an integer. Please read chapter 5 of the Java Language Specification if in doubt. — Preceding
unsigned comment added by
87.50.3.197 (
talk) 21:23, 12 June 2011 (UTC)
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):
In-doubt:
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)
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)
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:
using
is a classic example).The last part, BTW, reminds me of a quote that has stuck with me for years:
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:
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:
int
implies Int32
, ValueType
, and Object
), all those dependencies are definitely fair game.Any
), though they blur the line a bit, are library. Not that it matters, with Java lacking all this.EventListener
interface on the Java side. I don't want to just see "Java doesn't have this", but rather, briefly, what Java does instead. (The table of course has too little space for details, but the article text will elaborate.)I see the language as an "inner circle", a core that I will start with to learn the differences between Java and C#. The next bigger circle can include things like weak references and the collection classes. The most gigantic circles can extend to comparing, at a high level, WPF with Swing or whatever. These are all articles I would like to read, but ideally not all mixed together.
I'd like to trim down the feature table a bit. I'm afraid taking out the "yes, yes" items would leave a big column of "no" for Java and "yes" for C#, exacerbating the apparent bias. (If it came to that, it might be better to just have sections "C# features not in Java" and vice versa.) But it may actually be better to replace "yes" and "no" with, let's say,
Not that I will try myself, being so ignorant and biased.
-- SlothMcCarty ( talk) 05:52, 7 June 2011 (UTC)
I agree with you. The standard way of defining a listener in Java is by using interface EventListener. The standard way of defining a property is by following the JavaBeans specification. etc. And it's pretty obvious that the reason for which the Java language intentionally lacks some specific syntax for these features, is that they can be easily implemented in the class library instead, so that the language can be kept simple. Therefore, I think it definitely makes little sense to talk about the programming language without saying that, in a real-world application, you will typically make use of some BCL class instead of a language-specific keyword. -- 151.75.53.61 ( talk) 03:36, 10 June 2011 (UTC)
SlothMcCarty that is very well put. However, there exists some "core" libraries or types for both languages which could be considered part of the language. Some are even mentioned in the respective language specs. My feeling is that these should be allowed in regardless of specific syntactical support. For instance, the class type of Java and the Type type of C#. As I see it, using the criteria you suggested, we should get rid of the "platforms" table as well as the collections among others. I would suggest a criteria for the rest: Good explanation contrasting the languages should follow each table section. Useerup ( talk) 19:01, 14 August 2011 (UTC)
I am a C# programmer and have been since version 1.0 of the language, but my intimate knowledge of the language may be incomplete. With that said, my understanding of enumerations is that they are type-safe. Also, as far as I know, C# is completely type-safe. It impossible, or near, to do something in C# that is not type-safe.
Enumerations do not derive from integer types (8, 16, 32, or 64-bit), but instead derive from System.Enum which in turn derives from System.ValueType, System.IComparable, System.IFormattable, and System.IConvertible. System.ValueType implicitly derives from System.Object. So, enumerations are value types, but do not derive from any explicit value type. When specifying an integral type for an enumeration, you're merely telling the compiler and runtime what the enumeration's numerical limits are; not deriving from the integral type. The idea of deriving from an integral type is an erroneous one because integral types are value types. Value types are implicitly sealed which means you cannot derive from them.
Enumerations only allow you to assign the enumeration's defined values. Integral values can be assigned to an enumerated type through casting, but this can lead to having values outside the implied range (the defined values) of the enumeration. An exception to this rule is the value of zero, which can be assigned to an enumerated type without casting.
It is true that enumerations don't allow anything other than the enumeration values. But, the Enum class defines four ToString methods which will convert any enumeration to a string without the need to define an explicit ToString method on an enumeration. The Enum class also defines several other methods which makes working with any enumeration easy.
So in short, I propose that the section on Enumerations be revised. I don't know enough about Java to do it in a non-biased manner. — Preceding unsigned comment added by Skoobiedu ( talk • contribs) 06:47, 16 July 2011 (UTC)
Some contributors have hinted at what I'm going to say. Perhaps it should be stated directly.
It's "obvious" that a language with "more" and "better" features is the "superior" language, right? Well, maybe. This article ignores the point that the differences among languages aren't as important as the differences among the programs you write with these languages. For example...
How do Java's seeming "deficiencies" affect one's ability to implement a particular programming approach?
How often do programmers have to "work around" particular features in either language?
How do the languages' features and syntax affect one's ability to write clear, easily maintainted code?
In other words... how do the differences between Java and C# affect their utility as programming tools, including algorithmic "expressiveness"?
I'm sure programmers more-experienced than I will have caught things I've missed. But the article is too low-level; it overlooks the broader issues. WilliamSommerwerck ( talk) 20:57, 23 August 2011 (UTC)
Decimal is a fixed-point type. It's the exact opposite of floating point. The only thing they have in common is that they both can have a decimal point in their string representations. — Preceding unsigned comment added by 66.193.1.106 ( talk) 14:15, 7 September 2011 (UTC)
{{
cite web}}
: CS1 maint: location (
link)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 |
I tidied up these sections as there was some glaring misconceptions (delegates, events, closures and observer pattern were all lumped together) and some NPOV issues ("plain, old object-oriented design"). —Preceding unsigned comment added by Useerup ( talk • contribs) 04:54, 18 May 2010 (UTC)
Any idea what was intended when someone wrote:
In Java Operator Overloading is performed by language itself only Like '+' Operator. (String + any other object = String) and (int + int = int). but this facilities can not provide to our application. ( By- Bhanu Pratap Singh )
Makes little sense to me - hardly operator overloading at all. Removing. Amniarix ( talk) 19:43, 1 July 2009 (UTC)
In this article everybody is mixing up the runtime environment (JRE <-> .NET Framework) with language features. I think this is an error. Thomas Maierhofer ( talk) 12:47, 20 January 2009 (UTC)
Why does the data types chart say "No" for C# for "Big decimal (financial) type", and then provide a cite link to an article on the big decimal/financial data type "decimal" in the C# online reference? —Preceding unsigned comment added by Cerowyn ( talk • contribs) 18:04, 8 February 2010 (UTC) Big Decimal is a particular type of Arbitrary-precision arithmetic, which is supported in Java, Ruby or Python, but not in C#, which "only" has a decimal type defined with 128 bits maximum. Hervegirod ( talk) 21:43, 8 February 2010 (UTC)
I have started incorporating the "notations and special features" into the main body of the text while trying to preserve the examples. I started with "yield" and generator methods. This statement: "in C#, both the generic and non-generic versions must be implemented at the same time, adding length to the code" is false. I have removed it. If anyone can come up with a reference to such a requirement, please cite. Useerup ( talk) 08:20, 9 June 2010 (UTC) I also removed the reference to "Project Lombok". Lombok is 1) not a language, VM or library feature, 2) not from a 1st party (Sun/Oracle), 3) relying on brittle byte-code manipulation which is not compatible with all VMs and have known incompatibilities with IDEs. It does not belong here. Useerup ( talk) 09:05, 9 June 2010 (UTC)
The Operating Systems chart gives C# a "no" for Mac OS/X and the assorted flavors of Linux, and yet we have the Mono project mentioned just a few lines above. Did the author of the article forget to read Wikipedia's Mono article or the Mono web site? —Preceding unsigned comment added by 129.176.151.10 ( talk) 18:11, 17 June 2010 (UTC)
Why the "language only" restriction? In a article between C# and Java, a comparison of "language features" without their respected platforms is totally pointless and misleading. Virtually everyone who uses Java uses the standard libraries and likewise for C# (.NET). You realistically can not make a useful comparison between the languages without understanding the platforms. For instance: this article lists C# as "green" for Linux, despite Mono implementing a fraction of .NET proper.
I also question why suddenly now it was decided to remove the Collections comparison from the table. It was there for over a year. I think this clearly points to the bias in this article: before I added some collections Java has that .NET does not, no one seemed to care about this table. Why suddenly so much caring? Java's Collection Framework is actually quite good and well designed, somewhere where Java might have more "green" then C#. Oops! But when I did this (wrote in Collections that Java has that .NET doesn't, the whole table mas mysteriously removed. Suddenly it was "not relevant", I suppose.
Obviously having anything that would convey some sort of advantage to Java in a Java vs C# comparison would be a tragedy and must be removed with prejudice. Jbenjos ( talk) 23:15, 9 September 2010 (UTC)
I just removed the second sentence in this:
"In addition to this, C# can help mathematic applications with the checked and unchecked operators that allow to enable or disable run-time checking for arithmetic overflow for a region of code. It also offers rectangular arrays, that have advantages over regular nested arrays for certain applications.[18]"
This isn't true. C# provides a custom rectangular (or multidimensional) array syntax like this: "new Scalar[width, height]". However, that is basically functionally identical to what is commonly done in C++, Java, and C#: "new Scalar[width * height]". Also, the referenced .pdf paper was saying that most languages (such as Java which was mentioned) only have rectangular arrays and don't have direct language-level support for "block, symmetric, or sparse" arrays. I believe the author would consider Java to have rectangular arrays and that directly contradicts the rectangular array advantage for numeric applications mentioned in the Wikipedia entry.
Ramses89 ( talk) 19:04, 28 September 2010 (UTC)
To whoever made the edits claiming that C# does run-time type checking: I have reverted your edits because you are wrong. Java needs to put in type checks to be performed at runtime because of Javas type erasure. These checks are inserted into the code calling the methods of the generic. There is only one type in Java for each generic type: The raw type. C# generics are reified: There will be multiple "closed" type; one for each unique realization of the generic. The types methods and implementations are verified as type safe and need no extra type checks put into the calling ("client") code. Now, if you find the explanation in the article confusing let us discuss how to clarify. But please don't remove verifiable facts. Useerup ( talk) 20:48, 7 October 2010 (UTC)
The C# code in the article is highlighted (but not Jave code) to give it a "nicer" feel. —Preceding unsigned comment added by 14.96.184.114 ( talk) 22:49, 9 October 2010 (UTC)
The fundamental POV issue I see with this article is it seems to give the impression that C# is a better language then Java. How it accomplishes this is through a subjective idea of what is valid information in this article. I've tried to improve the neutrality of this article by spending a non-trivial amount of my own time adding things I believe are strengths of Java in comparison to .NET. However, more active editor(s) seem to be picking and choosing what features constitute "language features" and what features constitute "runtime features" within the context of this article, and quickly reverting any attempts I have made to make this article seem more balanced to the reader. These users will remove entire sections which they consider "runtime" features and reinstate others which in their opinion constitute "language features".
The problem at a fundamental level is not so much the separation of language and runtime for the purposes of comparison - it is that this kind of separation is not useful for a principled comparison. To make a analogy, it's like trying to useful comparison to car models based upon one or two of their major features, while picking this those features to promote a specific agenda in the comparison. You simply can not do this and remain neutral.
Even more concerning is that both C# and Java both rely on their respected runtime and standard libraries to derive language features! Separating runtime and language is an artificial separation, that's not entirely even possible. This is without regards to the fact that C# and Java programmers will be working with the respected standard libraries at such a deep level, such that ignoring their existence does not produce a realistic worldview of language capability.
Worse, this article gives the reader a incorrect perception about language comparison in general: that language features should be looked as a separate entity not alongside all the other capabilities of framework and tooling. Truth of the matter is, these things are as important if not more important then what is basically the built in syntactical macros of a language.
If you compare Java and .NET in the holistic manner, I am confident it is possible to create an article that is NPOV and truly shows the strengths and weaknesses of each camp with respect to each other. This article as it is, doesn't accomplish it. But it is certainly possible. Jbenjos ( talk) 17:23, 17 October 2010 (UTC)
I have just given a very careful reading to the 'introduction' section. In the process, I promoted it to being the
WP:LEDE (there wasn't one) and simplified some of the duplication I found (
). It seems to me after that process that what the introduction was trying to say, even before I altered it, was that this is a parent article, and that
Comparison of the Java and .NET platforms is a child article, per
WP:SPINOUT. This makes perfect sense: if I was a young student trying to decide which of these languages to learn, or a system architect deciding which to employ in a new development, or a chief executive deciding which to specialise the whole business upon, then this is the article I would expect to start at - the one with the most general name. This should cover all the relevant bases, in SPINOUT style, with links to more detailed articles about the platforms, the platform extensions (like Java EE, NANT, what-have-you), the developer bases, the support networks, the libraries, the licences, the benchmarks, the runtimes, scalability, everything. Two things we should not say here are (1) this is only about the curly braces and the while
loop syntax; (2) This article is nearly finished. --
Nigelj (
talk) 12:18, 18 October 2010 (UTC)
I tried finding something about tuples and C# on Google, but it just seems as if it's a normal object with two generic arguments? Doesn't Java have that as well? —Preceding unsigned comment added by 85.229.222.130 ( talk) 16:16, 23 October 2010 (UTC)
Recently the platform support was edited to show "partial" for C# on a number of platforms because the latest version of C# "wasn't even available" on those platforms. That was correct. Mono C# 4.0 has now been released for a number of platforms and I edited the platforms covered by Mono.
This was promptly reverted with a reference to "C# support on non Windows platforms is partial, because Mono does not support all of .NET framework (WPF, etc...))". I am sorry, but this article is still about C# and Java (the language) and not the .NET Framework or JRE. Developers developing games for iOS are very much programming in C# - but need not use the .NET Framework. Please help keep this article about the languages and take the library comparisons to comparison of .NET and Java. Thanks. Useerup ( talk) 00:52, 25 October 2010 (UTC)
for
loop have been extended to accept an interface for iterating through collections, so the for
loop has a dependency to the iterable interfaces as well which brings it preciously close to collections. IMO collections should not be here though. Similarly with platforms: They were initially introduced demonstrating that Java existed on a number of platforms where C# did not. But how does a programming language support a platform? If there exists a cross-compiler, certainly a developer can use the language to develop for that platform. Like Android. But then the entire platforms section becomes moot. IMO that comparison belongs in the comparison of the .NET and Java platforms where it can be properly qualified. In this context it just doesn't make sense.
Useerup (
talk) 22:09, 25 October 2010 (UTC)
Java does not support operators with these types. You cannot use the + or * operators, you have to use the member functions instead. This is an important difference between Javas types and the C# ones. Useerup ( talk) 09:30, 28 November 2010 (UTC)
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)
http://www.mono-project.com/Compatibility GeirGrusom ( talk) 12:01, 26 February 2011 (UTC)
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)
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)
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)
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)
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.
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.
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.
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)
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.
Seems to me that there are plenty of significant differences, right? Useerup ( talk) 23:38, 21 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: 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
You cannot say something is OO and miss basic features of being OO see
http://en.wikipedia.org/wiki/Object-oriented_programming.
Please don't undo the dispute in the section until this is resolved.
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)
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 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)
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)
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"
// 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
}
// 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]
}
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 = array0 == 25 ; // fast: no unboxing involved
array0 += 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 MyValueTypesize;
for(int i = 0; i < size; ++i)
{
// for the following line
// allocation on GC part: 1 for MyValueType and 1 for MyValueTypeSize
arrayi = 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)
arrayi.increment(42);
arrayi.increment(true, 5.55);
arrayi.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 MyValueTypesize];
for(int i = 0; i < size; ++i)
{
// for the following line
// no allocation on GC part.
// Everything is modified in the array
arrayi = 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
arrayi += new MyValueType(42);
arrayi += new MyValueType(true, 5.55);
arrayi += new MyValueType(i * 25, 0.05 * i, ((i + 1) % 2) == 0);
}
}
And please note that this difference is not mere plain syntactic sugar: There is a major performance cost involved there (allocating millions of small objects is always a problem, both in speed in low-latency cases, and in memory in large data cases).
Paercebal ( talk) 15:50, 23 April 2011 (UTC)
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)
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)
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)
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)
This section is obviously misleading. Mono does not support all the features that we have added in c# column (e.g. functional programming). This table actually says us that C# is multiplatform language but it is not. — Preceding unsigned comment added by 77.37.180.86 ( talk) 18:11, 20 June 2011 (UTC)
Functional programming is supported by MS C# or Mono C#. Mono supports C# 4 in full ( http://www.mono-project.com/Compatibility). Please remember that this is not a framework comparison, but a comparison of two programming langauges. Functional programming refers to lambdas, closures and the fact that functions are 1st class objects in C# 3+, supported on all platforms. Useerup ( talk) 21:56, 23 June 2011 (UTC)
I don't believe you can compare C# to Java without including the framework. Because the framework itself supplements what the language does not support. And what is, and is not moved from the language into the framework is of itself a debated topic.
Lambda Expressions, however, are an extension to the C# language. Just like Macro's are an extension to the C++ language. Neither are the language, even if they are mingled together like they are. 173.167.141.1 ( talk) 18:56, 28 July 2011 (UTC)
Lambda expressions are part of the C# language spec. It is not an extension to the language any more than the for loop is. As for including "the framework" please see the discussion on this very topic elsewhere on this page. It is a difficult nut to crack because you are of course right that some language features are complemented or replaced by framework features. But what parts of the framework should then be used as base for the comparison? java.lang? (yes) java.util? (probably yes, some of it), java.awt? (no!). Useerup ( talk) 16:02, 30 July 2011 (UTC)
Added Windows Phone to the platforms table.
I reverted an edit claiming that the Java char
type is an "unsigned 16 bit integer" type. According to the language spec it is an integral type which as soon as it is used with a numeric operator (such as bitwise shift, -and and -or ) it gets promoted to an integer. So the char
type is not an integer type, neither formally nor practically. It is a separate integral type which is convertible to integer but is itself not an integer. Please read chapter 5 of the Java Language Specification if in doubt. — Preceding
unsigned comment added by
87.50.3.197 (
talk) 21:23, 12 June 2011 (UTC)
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):
In-doubt:
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)
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)
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:
using
is a classic example).The last part, BTW, reminds me of a quote that has stuck with me for years:
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:
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:
int
implies Int32
, ValueType
, and Object
), all those dependencies are definitely fair game.Any
), though they blur the line a bit, are library. Not that it matters, with Java lacking all this.EventListener
interface on the Java side. I don't want to just see "Java doesn't have this", but rather, briefly, what Java does instead. (The table of course has too little space for details, but the article text will elaborate.)I see the language as an "inner circle", a core that I will start with to learn the differences between Java and C#. The next bigger circle can include things like weak references and the collection classes. The most gigantic circles can extend to comparing, at a high level, WPF with Swing or whatever. These are all articles I would like to read, but ideally not all mixed together.
I'd like to trim down the feature table a bit. I'm afraid taking out the "yes, yes" items would leave a big column of "no" for Java and "yes" for C#, exacerbating the apparent bias. (If it came to that, it might be better to just have sections "C# features not in Java" and vice versa.) But it may actually be better to replace "yes" and "no" with, let's say,
Not that I will try myself, being so ignorant and biased.
-- SlothMcCarty ( talk) 05:52, 7 June 2011 (UTC)
I agree with you. The standard way of defining a listener in Java is by using interface EventListener. The standard way of defining a property is by following the JavaBeans specification. etc. And it's pretty obvious that the reason for which the Java language intentionally lacks some specific syntax for these features, is that they can be easily implemented in the class library instead, so that the language can be kept simple. Therefore, I think it definitely makes little sense to talk about the programming language without saying that, in a real-world application, you will typically make use of some BCL class instead of a language-specific keyword. -- 151.75.53.61 ( talk) 03:36, 10 June 2011 (UTC)
SlothMcCarty that is very well put. However, there exists some "core" libraries or types for both languages which could be considered part of the language. Some are even mentioned in the respective language specs. My feeling is that these should be allowed in regardless of specific syntactical support. For instance, the class type of Java and the Type type of C#. As I see it, using the criteria you suggested, we should get rid of the "platforms" table as well as the collections among others. I would suggest a criteria for the rest: Good explanation contrasting the languages should follow each table section. Useerup ( talk) 19:01, 14 August 2011 (UTC)
I am a C# programmer and have been since version 1.0 of the language, but my intimate knowledge of the language may be incomplete. With that said, my understanding of enumerations is that they are type-safe. Also, as far as I know, C# is completely type-safe. It impossible, or near, to do something in C# that is not type-safe.
Enumerations do not derive from integer types (8, 16, 32, or 64-bit), but instead derive from System.Enum which in turn derives from System.ValueType, System.IComparable, System.IFormattable, and System.IConvertible. System.ValueType implicitly derives from System.Object. So, enumerations are value types, but do not derive from any explicit value type. When specifying an integral type for an enumeration, you're merely telling the compiler and runtime what the enumeration's numerical limits are; not deriving from the integral type. The idea of deriving from an integral type is an erroneous one because integral types are value types. Value types are implicitly sealed which means you cannot derive from them.
Enumerations only allow you to assign the enumeration's defined values. Integral values can be assigned to an enumerated type through casting, but this can lead to having values outside the implied range (the defined values) of the enumeration. An exception to this rule is the value of zero, which can be assigned to an enumerated type without casting.
It is true that enumerations don't allow anything other than the enumeration values. But, the Enum class defines four ToString methods which will convert any enumeration to a string without the need to define an explicit ToString method on an enumeration. The Enum class also defines several other methods which makes working with any enumeration easy.
So in short, I propose that the section on Enumerations be revised. I don't know enough about Java to do it in a non-biased manner. — Preceding unsigned comment added by Skoobiedu ( talk • contribs) 06:47, 16 July 2011 (UTC)
Some contributors have hinted at what I'm going to say. Perhaps it should be stated directly.
It's "obvious" that a language with "more" and "better" features is the "superior" language, right? Well, maybe. This article ignores the point that the differences among languages aren't as important as the differences among the programs you write with these languages. For example...
How do Java's seeming "deficiencies" affect one's ability to implement a particular programming approach?
How often do programmers have to "work around" particular features in either language?
How do the languages' features and syntax affect one's ability to write clear, easily maintainted code?
In other words... how do the differences between Java and C# affect their utility as programming tools, including algorithmic "expressiveness"?
I'm sure programmers more-experienced than I will have caught things I've missed. But the article is too low-level; it overlooks the broader issues. WilliamSommerwerck ( talk) 20:57, 23 August 2011 (UTC)
Decimal is a fixed-point type. It's the exact opposite of floating point. The only thing they have in common is that they both can have a decimal point in their string representations. — Preceding unsigned comment added by 66.193.1.106 ( talk) 14:15, 7 September 2011 (UTC)
{{
cite web}}
: CS1 maint: location (
link)