Talk:Comparison of C Sharp and Java
 | Java Start‑class Low‑importance | |||||||||
| ||||||||||
 |
Links from this article with broken #section links : You can remove this template after fixing the problems | FAQ | Report a problem |
| Links from this article which need disambiguation (check | fix): [[CLR]], [[generics]]
For help fixing these links, see Wikipedia:WikiProject Disambiguation/Fixing a page. Added by WildBot | Tags to be removed | FAQ | Report a problem |  |
|
This page has archives. Sections older than 90 days may be auto-archived by Lowercase sigmabot III if there are more than 4. |
Platform support
This section is obviously misleading. Mono does not support all the features that we have added in c# column (e.g. functional programming). This table actually says us that C# is multiplatform language but it is not. — Preceding unsigned comment added by 77.37.180.86 (talk) 18:11, 20 June 2011 (UTC)
Functional programming is supported by MS C# or Mono C#. Mono supports C# 4 in full (http://www.mono-project.com/Compatibility). Please remember that this is not a framework comparison, but a comparison of two programming langauges. Functional programming refers to lambdas, closures and the fact that functions are 1st class objects in C# 3+, supported on all platforms. Useerup (talk) 21:56, 23 June 2011 (UTC)
Value types
C# value types are not syntactic sugar. To meet that definition you would have to demonstrate what kind of code is really generated which you could have written yourself. You cannot do that with value types as they exhibit copy semantics - i.e. they are stack allocated and new copies are created when assigned or passed as parameters. Apart from that, being "syntactic sugar" is not an impeachment. Every single programming language is rife with "syntactic sugar". For loops are syntactic sugar: You can demonstrate how the resulting code can be generated as a result of statements and a while loop (or vice versa). Syntax matters. Useerup (talk) 22:26, 25 October 2010 (UTC)
- Response: Value types are not a language feature,end of story, your wrong , give it up. Nobody outside Redmond and MS Fanboys cares about value types. They are not defined in any computer science literature, they are an invented type by MS. Not once in programming in C/C++/python/ruby/java/ADA/perl have I ever heard someone say 'geez wiz I wish I had value types'. You really need to stop arguing with everyone on this page. You keep reverting peoples changes, pretty much disagreeing with everyone where they are saying there is bias. How are we suppose to get rid of bias if you are allowing any real changes? —Preceding unsigned comment added by Bongey (talk • contribs) 14:46, 26 October 2010 (UTC)
- "Value types" is a kind of language feature.
In Java, they are called primitives.
In C++, the difference can be summed as "Do I own the object directly, or through a (smart of not) pointer?". The difference is very important, as in C++, the last thing you want is to allocate everything through a new, if only because of performance reasons. But I should not have to explain you this, as you claim extensive experience in C++.
Anyway, this is exactly the reason why in Java primitives are not objects (I was told they tried having all primitives being true objects at first, but turned back because of performance).
In C#, they made Value Types derived from Object, but still made them "primitives" as understood by Java.
So Value Types are, as primitives, a language feature.
Fact is, Value Types as understood by C# are a first-class citizen of C#, when their equivalent (primitives) are not in Java:
C# handles boxing/unboxing when needed, and does not impose boxing/unboxing when it is not needed, for example.
Java is unable to handle primitives correctly without always boxing them first (for example, in generics).
Thus, the difference in handling Value types/primitives by the two languages is very important, and should be explicit in the current article.
Paercebal (talk) 13:05, 23 April 2011 (UTC)
- "Value types" is a kind of language feature.
- I fail to see what's specific in Value Types, except Microsoft's marketing maybe. In .NET value types are also boxed / unboxed, because .NET really wraps the primitive values in Objects, and this operation cost a lot, like in Java. Also transparent boxing / unboxing of primitives is also managed in Java, for example this is perfectly valid Java code:
List<Integer> list = new ArrayList(); list.add(2); int value = list.get(0);
More than that, if you try to code the same examples provided by Microsoft to explain how Value Types are working, these examples also work in Java, with an almost identical syntax.Hervegirod (talk) 21:41, 24 June 2011 (UTC)
You are mistaken, value types are not boxed/unboxed in .NET like they are in Java. This would be the code in C#:
var list = new List<int>(); list.add(2); int value = list[0]
And it would not involve the relatively expensive boxing and unboxing conversions. This goes for any primitive and value type (primitive types are just a subset of value types). int is a value type, and in C# you can define new value types. Only when value types are treated like objects (reference types) are they boxed. You may declare arrays of custom value types and the array will contain the actual values not a boxed references to values. Useerup (talk) 23:23, 26 June 2011 (UTC)
Is this entire article directly lifted from some page at microsoft.com?
Because it looks like it. It reads like an essay and one that seems to be written for Java programmers to switch to C#. Rajakhr (talk) 09:21, 18 May 2010 (UTC)
- If you compare two things, and one appears better, you can either:
- Hide your head in the sand, and claim it's a conspiracy
- Add meaningful and truthful arguments that were forgotten
- Accept the apparent better one is the better one.
So please, contribute in a meaningful and truthful way, if possible...
Paercebal (talk) 13:04, 23 April 2011 (UTC)
- Besides, the goal of this comparison is not to determine which language or feature is better, but simply to allow programmers to compare possibilities for expressing things in the two languages. Rp (talk) 08:03, 7 June 2011 (UTC)
Setting the ground rules
Rather than speculating what motives we each might have for wanting a certain section (green or red?) included or not, I suggest that we set some ground rules here. It is a complicated issue and there are some gray areas, but with a lot of the topics I think we should be able to come to a consensus.
IMO the overall goal should be a comparison between the two languages as they are experienced by new programmers learning just the language and basic library as they are used across all reasonable disciplines.
Both languages were designed alongside their respective VMs. That a language happens to not have a specific syntactic construct for a given feature, but only a "library" feature does not rule that feature out. Case in point: Java's "soft" references. This is a VM feature which has no specific syntactic representation. It can only be used through a core library. But this feature exists and soft references has semantics different from weak references.
Likewise, some of C# conditional compilation features and assertions - which are clearly language features - do not have specific syntactic constructs. Instead they are used by adorning methods with metadata which is understood by the compiler. While attributes is a language feature, those specific attributes are defined in a library.
Clearly, we cannot draw the line just at the language specification. Significant features would be left out of both languages. To complicate matters, corresponding concepts are sometimes surfaced with syntax elements while the almost exact same feature (clearly present) in the other language has been factored as library feature giving access to the VM feature. Case in point: Synchronization. This was introduced in Java before annotations, hence synchronization is declaratively set with a language keyword. C# had annotations ("attributes") from the start, and chose to surface the almost exact same feature through concrete metadata attributes. Does that mean that C# does not have declarative synchronization? Clearly not! The underlying synch mechanisms of the VMs are just surfaced through different channels.
Because we clearly need to allow some "core" libraries from both languages we need to set some rules for what is in-scope and what is out of scope. In my opinion this article *should not* deteriorate into a comparison of application servers. That is taking it too far.
My initial suggestion is (feel free to suggest changes):
- VM features are in-scope whether they are surfaced through language keywords or syntax or a *core* library
- C# System namespace "contains fundamental classes and base classes that define commonly-used value and reference data types, events and event handlers, interfaces, attributes, and processing exceptions" (quote documentation)
- Java's java.lang "Provides classes that are fundamental to the design of the Java programming language" (quote documentation)
- C# 'System.Collections' and 'System.Collections.Generic' because all developers uses collections and you couldn't imagine a modern language without standard collection types
- Java's collections etc. from java.util.* because all developers uses collections and you couldn't imagine a modern language without standard collection types
- C# System.Linq (but not System.Data.Linq etc) namespace, because LINQ clearly is a language feature and this is where it is surfaced (this is the LINQ to objects stuff and the general LINQ stuff - nothing remotely comparable to Hibernate, JDO or JPA)
- Java's java.lang.annotations - because this is how annotations (clearly a language feature) are surfaced.
- Java's java.lang.ref - weak and soft references which is basic interaction with the GC
- C#'s System.Reflection and System.Reflection.Emit namespaces - reflection is tightly coupled to both languages
- Java's java.lang.reflect package - reflection is tightly coupled to both languages
In-doubt:
- Java's java.math - big integers and decimals
- Java's java.text
- C#'s System.Collections.Concurrent. With .NET4 and task parallelism this is almost a 1st class concept. but...
- C#'s System.Numerics - big integers and complex numbers —Preceding unsigned comment added by Useerup (talk • contribs) 21:23, 10 September 2010 (UTC)
Response
Wikipedia is not original research I'd like to also take point in the fact that this article seems to be talking about a language called "Java". But this language that the article seems to refer to doesn't exist. Indeed, it's part of the requirement of all Java implementations to include certain functionality in their class library. Making a comparison between Java and C# and not including Java's standard library in the comparison is not really comparing Java and C#.
Wikipedia is verifiable It seems interesting that you want to include your own subjectivity into articles by randomly including and excluding namespaces as it suits you. But that's not how Wikipedia works. If you really thing System.Linq is part of C# and not .NET, you need verifiable references. It's not Wikipedia's job to invent language features. Or we can just include the standard class libraries of BOTH languages in this article. Which is a more useful comparison. Jbenjos (talk) 00:21, 12 September 2010 (UTC)
- This article is not research. Every fact should be verifiable by an authoritative source, otherwise it doesn't belong here. Do you find any such issues then fix them or report them here. The language specifications are clearly authoritative sources. If a concept (such as query expressions and expression trees) are mentioned in the specification as a language feature then it certainly belongs here. Do you have a problem with that? Why would you want to exclude something which are in the language specification?
- Java most certainly exists as a programming language. I believe you may be confused about the relationship between the language, the virtual machine and the standard class library. This is NOT a comparison of the VMs. This is NOT a comparison of the entire stacks (.NET versus Java SE/EE). There are other articles for that. This is a comparison between programming languages. Now, are there perfect demarcation lines between the VM, the language and the BCLs? No, the lines are murky. I gave several examples of that above.
- I am aware that a very narrow definition (e.g. only the language specs) could misrepresent one or both of the languages. If a certain feature is part of one of the languages but the designers of the other language opted to put a similar feature into the BCL, then it would not be an accurate representation to say one language has it while the other one doesn't.
- However, if you decide that "BCL" means JavaSE) you also include awt, swing etc. These are obviously NOT language features.
- My list above was an attempt at a discussion here about where to draw the lines. Instead of wild accusations, perhaps you would care to engage in such a discussion? —Preceding unsigned comment added by Useerup (talk • contribs) 22:01, 12 September 2010 (UTC)
- Can you please point to this class library lacking programming language called "Java"? I'm sure Oracle would like to know about it. You CAN NOT call something Java that doesn't pass the Java certification process - which includes a wide implementation of the class library Jbenjos (talk) 00:48, 25 September 2010 (UTC)
- Please explain, do you say that there is no such thing as "the Java programming language" because Oracle will not allow a 3rd party to market anything using the Java trademark unless it implements the full JavaSE? —Preceding unsigned comment added by 83.94.199.190 (talk) 17:26, 29 September 2010 (UTC)
- The most authoritative source for anything Java language is: Java™ Language Specification, Third Edition, The. By: James Gosling; Bill Joy; Guy Steele; Gilad Bracha. Publisher: Prentice Hall. Print ISBN-10: 0-321-24678-0. Please point us to where in this specification (this is the specification) it says anything about: AWT, Collection classes, application servers, platforms, enterprise etc. What you will find is that it says something about strings, classes, generics and type erasure, blocks and statements, expressions and binary compatibility. Why is it so hard to make a comparison of programming languages just about the languages. If you feel that Java (the ecosystem) or JEE has so many advantages that you absolutely *must* declare them to the world, then please edit the correct article for that. This is not the correct article for comparing enterprise stacks or platform deployments. This article is about programming languages, you know, like C++, C, Python, LISP etc. Useerup (talk) 15:20, 30 September 2010 (UTC)
- Can you please point to this class library lacking programming language called "Java"? I'm sure Oracle would like to know about it. You CAN NOT call something Java that doesn't pass the Java certification process - which includes a wide implementation of the class library Jbenjos (talk) 00:48, 25 September 2010 (UTC)
Response: I think the comparison should be limited to pure computer science concepts, not invented by either sun or microsoft. if you are purely doing a language comparison. Many of features in C#, when opening up my programming languages book are not defined. If there is no universal definition to programming feature , it should be left out, if you are just doing a language comparison. —Preceding unsigned comment added by Bongey (talk • contribs) 20:46, 25 October 2010 (UTC)
- Because neither Sun nor Microsoft has or could contribute to the body of knowledge referred to as "computer science"? —Preceding unsigned comment added by 76.23.17.34 (talk) 02:17, 13 February 2011 (UTC)
Another response - drawing the line
There is a wealth of good discussion here, and I hope my humble contribution can advance it. I came here as a long-time C# programmer orienting myself to Java. As such, an article like this is certainly a useful reference (a "keep").
It's pretty obvious that C# is more feature-rich than Java, as a language, for better or for worse. It's hardly biased or even surprising. But note:
- Most of the time, a "feature" in one language is at least something that can be done in the other, or even in C for that matter, in a more roundabout way. But when that's not the case, it is a key point to note.
- Language features are good--if I may say that with neutrality--in that they simplify or streamline something valuable (C#
usingis a classic example). - They are bad in that they add complexity to the language itself. If a dozen specialized keywords can be eliminated in favor of one general-purpose solution, the language may be better off. Perhaps the feature-poor Java has a cleaner way of doing something with existing facilities.
The last part, BTW, reminds me of a quote that has stuck with me for years:
- "There is only one small problem--modifying the C++ standard is as easy as running for President of the United States. When I mentioned my idea to Bjarne Stroustrup, he looked at me as if I just asked him to lend me a thousand dollars. Then a sudden idea struck me. I can implement strong pointers myself...."
That said, weighing the respective merits of Java's approach versus C#'s is not our task; illuminating the differences is. Readers such as myself are less interested in the which-is-better debate and more interested in understanding how constructs in one language translate most succinctly into the other. To that end, a yes/no feature chart is somewhat useful and a good starting point or summary (the yes, yes lines strike me as a bit silly, though). More useful still is an item-by-item comparison of "this is the C# way" versus "this is the Java way".
Useerup, I agree wholeheartedly with your comments above and elsewhere, if not your detailed list.
We can frame our discussion by asking:
- What aspects are really part of the language (rather than the libraries or VM)?
- What is the most useful and natural topic of comparison--strictly the languages, or also some related issues in the libraries and VM?
The second question is important because, if we find it difficult and not worthwhile to draw the fine line between C# and .NET or between the Java language and Java, we should consider adjusting the topic of the article to something more natural and useful. That said, I prefer not to be expansive, as comparing all the other stuff is typically far less valuable than comparing fundamental syntax and capabilities.
Now some specifics:
- To the extent that the language depends on a very small part of the class libraries (e.g. C#
intimpliesInt32,ValueType, andObject), all those dependencies are definitely fair game. - Features of the VM accessed only through libraries, such as the various shades of weak references, are noteworthy but not really part of the language. I imagine that a novel VM (the next Dalvik, say) might handle things differently without violating the language itself.
- Reflection, of course, is of great interest, but consider this: a VB.NET program can use reflection to inspect compiled code written in C#, though it cannot tell that the source was C#. It's a subtle but real distinction. Reflection is really only indirectly related to the languages via the bytecode.
- Collections, fundamentally important as they are, are just libraries. So what if the .NET BCL doesn't include a priority queue class? You can easily add that class from another library, or write it yourself. In the same vein, so what if Java doesn't have complex numbers? (Contrast with generics, which must necessarily be baked in from the start.)
- LINQ is clearly an important language feature. Particular extension methods (e.g.
Any), though they blur the line a bit, are library. Not that it matters, with Java lacking all this. - Boxing is not exactly a syntactic issue, but it is critical for understanding what you are really telling the program to do (Paercebal talked about this at length elsewhere here). In general, when differences under the hood bleed into the languages, they are worth explaining.
- Again, let me emphasize that library features are worth mentioning by way of contrast or alternative to syntactic features in another language. For example, mentioning C#'s native event-handling features might naturally entail mentioning the
EventListenerinterface on the Java side. I don't want to just see "Java doesn't have this", but rather, briefly, what Java does instead. (The table of course has too little space for details, but the article text will elaborate.)
I see the language as an "inner circle", a core that I will start with to learn the differences between Java and C#. The next bigger circle can include things like weak references and the collection classes. The most gigantic circles can extend to comparing, at a high level, WPF with Swing or whatever. These are all articles I would like to read, but ideally not all mixed together.
I'd like to trim down the feature table a bit. I'm afraid taking out the "yes, yes" items would leave a big column of "no" for Java and "yes" for C#, exacerbating the apparent bias. (If it came to that, it might be better to just have sections "C# features not in Java" and vice versa.) But it may actually be better to replace "yes" and "no" with, let's say,
- native syntax
- library (no, but...)
- none
Not that I will try myself, being so ignorant and biased.
--SlothMcCarty (talk) 05:52, 7 June 2011 (UTC)
I agree with you. The standard way of defining a listener in Java is by using interface EventListener. The standard way of defining a property is by following the JavaBeans specification. etc. And it's pretty obvious that the reason for which the Java language intentionally lacks some specific syntax for these features, is that they can be easily implemented in the class library instead, so that the language can be kept simple. Therefore, I think it definitely makes little sense to talk about the programming language without saying that, in a real-world application, you will typically make use of some BCL class instead of a language-specific keyword. --151.75.53.61 (talk) 03:36, 10 June 2011 (UTC)
Value types (again)
Value types are *not* a C# invention. Even Java has the "primitive" types which has the same semantics. Only Java does not allow developers to specify their own value types, C# does. Value types are not a C# invention, even Pascal and C++ has them. In Pascal they are called "records". C++ has them not as an explicit concept, but any type act as a value type when used as an automatically (stack allocated) variable. So can we please lay this discussion to rest? Useerup (talk) 09:30, 28 November 2010 (UTC)
- There is a big difference between C/C++ structures and value types because structures in C or C++ are passed by reference, and they are passed by value in C#. It's the same in Pascal, where records are passed by reference too. Plus there are two kinds of Value types in C#: structures and enumerations. There are enumerations in Java too. Which means that the Value type line is misleading and incorrect. What would be correct would be to have two lines: structures (C# has, Java has not), and enumerations (the two languages have). There is also a specificity in C# because structures are passed by values (contrary to what is done in other languages which have this concept). I have another problem with the table, and most of the article: with almost NO sources, it is 90% OR, even if I agree that a lot of the text may be right. Hervegirod (talk) 14:41, 28 November 2010 (UTC)
- I think you may want to read up on C++ and Pascal. If I define a class (or struct) in C++ and declare a local variable of that class, it is *not* a reference; it is an automatic (look it up) object. It is automatically constructed (using a default constructor) and automatically destroyed. It has copy semantics: If I define another variable of the same type and assigns the forst one to it, C++ will "shallow" copy the members from the 1st object to the 2nd (actually, C++ will just copy the memory representation of the object). Also, C++ passes parameters of such type by value, unless you explicitly specify a pointer or reference type. Demonstration:
class Zem
{
public:
char* question;
int answer;
};
Zem zem1, zem2;
zem1.question = "The life, universe and everything?";
zem1.answer = 42;
zem2 = zem1;
zem2.question = "What is six times nine?";
std::cout << zem1.question << " " << zem1.answer << std::endl; // outputs "The life, universe and everything? 42"
std::cout << zem2.question << " " << zem2.answer << std::endl; // outputs "What is six times nine? 42"
- As you can see, zem2 is copied from zem1, but their "questions" clearly refer to different objects. If they had been copied by reference there would be only one question. Useerup (talk) 07:49, 29 November 2010 (UTC)
- @Hervegirod : "There is a big difference between C/C++ structures and value types because structures in C or C++ are passed by reference" : You're wrong. In C and C++, you can pass a struct by copy:
// C++ code
struct Value
{
int i;
double j;
std::string s;
} ;
void foo(Value p_value)
{
// p_value is a copy of the original variable
}
void bar()
{
Value value ;
foo(value) ; // value is passed by copy
}
- Fact is, in C++, you can pass whatever you want by copy or reference (my personal preferred curiosity being the reference to a pointer) or even const reference. The "Value Type" semantics exists, too, on C++: Anything pointed to could be considered to not be a value type (a pointed type? ... :-) ...), but all this discussion is blurred by the fact you have references or pointers to a value type, even when allocated on the stack:
// C++ code
void foo()
{
int i = 0 ; // "C# value type"/"Java primitive"
int j = i ; // j is now a copy of i, but a distinct one.
int & ri = i ; // ri is an alias/reference to i
int * pi = &i; // pi points to i
i += 2 ; // now, ri == 2 (and *pi == 2), but j == 0 [value type semantics]
ri += 3 ; // now, i == 5 (and *pi == 5), but j == 0 [value type semantics]
*pi += 4 ; // now, i == 9 (and ri == 9), but j == 0 [value type semantics]
pi += 4 ; // now, pi is invalid [pointer semantics]
}
- In C++, the value type (or concrete type) would be something whose meaningful value you access directly.
Whereas the pointer type would be something to be access indirectly, through pointer dereferencing, but if you play directly with the pointer (i.e. its address value), then lose its meaningful value (and in the example above, you have a bug). So there is a notion of value types vs. pointed types in C++ (which mirrors the difference between value types and reference types in Java/C#).
Paercebal (talk) 15:12, 23 April 2011 (UTC)
- In C++, the value type (or concrete type) would be something whose meaningful value you access directly.
I confirm about value types being an important topic. Two examples comparing Java and C# code. Please bear in mind that the point is to use light-weight types (as in: not using the GC or boxing/unboxing as much as possible):
In Java and C#, the "Value Type" is an existing language concept (called primitive in Java).
This can be summed up to: Do you access the data through a reference, or do you access it directly? But despite their similarity, C# Value Types and Java primitives have some important differences:
C# Value Types are C# objects, whereas Java primitives are not Java objects, meaning C# can (and does handle) Value Types both efficiently and genericly, whereas Java cannot handle primitives both efficiently and genericly.
For example, for build-in value/primitive types:
// Java code
void foo()
{
// testing a build-in primitive
int i = 42 ;
// testing Object Oriented properties of a Java primitive
i.toString() ; // WON'T COMPILE because int is not an Object
new Integer(i).toString() ; // will compile, but will be slow: manual boxing involved
// Testing generic containers of java primitives
Vector<int> array = new Vector<int>() ; // WON'T COMPILE !!!
Vector<Integer> array = new Vector<Integer>() ; // only way to have a vector of ints
// Testing boxing/unboxing of java primitives
array.add(i) ; // slow: autoboxing involved
boolean b = array.get(0) == 25 ; // slow: auto-unboxing involved
array.get(0) += 5 ; //WON'T COMPILE !!!
}
C# code
void foo()
{
// testing a build-in value type
int i = 42 ;
// testing Object Oriented properties of a C# value type
i.ToString() ; // fast: no boxing involved
// Testing generic containers of C# value types
List<int> array = new List<int>() ;
array.Add(i) ; // fast: no boxing involved
bool b = array[0] == 25 ; // fast: no unboxing involved
array[0] += 5 ; // fast: and now, 1st element of array is 47
}
The example above shows that C# handle build-in value/primitive types efficiently, and as first class citizens (C# value types have methods, and derive from Object, while Java don't).
The example below will show a Java and C# implementation of an aggregation of data. This data needs to be mutable, needs to used in arrays of millions of those those data, and could be used as keys for Hash tables/maps. Being able to handle those data with value copy semantics is important, too (i.e. the assignment creates a deep copy, not a clone).
So, for those user-defined types supposed to behave like value/primitive types:
// Java code
// Of course, there is no way to have user-defined primitives,
// so will use full Java classes instead
class MyValueTypeSize
{
public int quantic ;
public double length ;
// constructors, methods, etc.
}
class MyValueType
{
public boolean truthness ;
// This will need the allocation a separate MyValueTypeSize on the GC heap
public MyValueTypeSize size ;
// constructors, methods, etc.
}
// etc.
void foo()
{
// allocation of one array of contiguous of 1-million references to items
// (i.e. each item will be allocated separately)
int size = 1000000;
MyValueType[] array = new MyValueType[size];
for(int i = 0; i < size; ++i)
{
// for the following line
// allocation on GC part: 1 for MyValueType and 1 for MyValueTypeSize
array[i] = new MyValueType(i, 3.1415 * i, (i % 2) == 0);
// for the following lines
// to avoid new allocation on GC part, the code must be written
// very carefully. We choose to write a specific method increment
// (there are possibly one increment method for each constructor)
array[i].increment(42);
array[i].increment(true, 5.55);
array[i].increment(i * 25, 0.05 * i, ((i + 1) % 2) == 0);
}
}
C# code
// testing user-defined value types
struct MyValueTypeSize
{
public int Quantic ;
public double Length ;
// + constructors, operators, etc., as needed
}
struct MyValueType
{
bool Truthness ;
// no need for a separate GL allocation for this...
public MyValueTypeSize Size ;
// ... so, for all intents, we can consider MyValueType
// to be an aggregation of an int, a double and a bool
// in the same structure
// + constructors, operators, etc., as needed
}
// etc.
void foo()
{
// allocation of one array (whose size is enough to contain 1-million
// contiguous items)
int size = 1000000;
MyValueType[] array = new MyValueType[size];
for(int i = 0; i < size; ++i)
{
// for the following line
// no allocation on GC part.
// Everything is modified in the array
array[i] = new MyValueType(i, 3.1415 * i, (i % 2) == 0);
// for the following lines
// no allocation on GC part
// Note that here is only ONE operator + defined to handle the
// following lines, instead of one overload for each MyValueType
// constructor in Java
array[i] += new MyValueType(42);
array[i] += new MyValueType(true, 5.55);
array[i] += new MyValueType(i * 25, 0.05 * i, ((i + 1) % 2) == 0);
}
}
And please note that this difference is not mere plain syntactic sugar: There is a major performance cost involved there (allocating millions of small objects is always a problem, both in speed in low-latency cases, and in memory in large data cases).
Proposal for Deletion
I believe this article should be removed.
First, I believe it is meaningless to try to compare the languages separately from the run-time libraries. Indeed, the article does not, and makes arbitrary choices about whether to include or exclude library features. Both languages are fundamentally useless without at least some library, and are designed to work with library support.
Second, the cited sources are either opinion, or relate only to one language or the other. As such, I believe this article is a synthesis of published material, and therefore contravenes the policy on original research.
Spockwithabeard (talk) 14:39, 19 February 2011 (UTC)
- This article has become a kind of forums where C# advocates like to push their own Point of views, I think without even knowing they are doing this. For example, there was a lengthy discussion where people considered that java did not have events, because part of the events framework was provided by the BCL. But the same people have no problem to write that C# has Expression trees or Query language, where it is only a BCL feature. Hervegirod (talk) 14:33, 6 March 2011 (UTC)
- BTW, I'm not sure about expression trees, but LINQ querying is definitely a language feature. Rp (talk) 17:12, 16 March 2011 (UTC)
I agree that there is original synthesis going on here. If we are to have an article on this subject, then the sources should limited to reliable publications that explicitly compare C# and Java. I don't think there are many of those - maybe the introductory sections of some books that then go on to describe one language or the other in detail. Of course, if those books are themselves published by Microsoft or Sun (Oracle), then they are hardly neutral. As it stands, this article is mostly a mess of "mine is bigger than yours" bragging by fans, and not much use to ordinary readers. I tried to join in the discussion about events, but just got shouted down, from what I remember. I haven't bothered since, and that's no way to run a WP article. --Nigelj (talk) 16:31, 6 March 2011 (UTC)
To make my point more clear, we need to start from "The developers of Java based it on the C++ programming language, but removed many of the language features that are rarely used or often used poorly."[1] (I can't remember where I first came across that on Sun's old website). What C# seems to have done (although Microsoft won't admit it) is start by directly copying the Java language and concept, then, release by release, adding back in various C++, VB and other random concepts, whether they are or could be used poorly or not. This article repeats, "C# has this; does Java have this? No? Fail." It does this without considering why the feature was left out of Java, what the pros and cons of providing developers with the feature are, or any other relevant issue. Take the first point in the comparison table: "Single-root (unified) type system? Java No; C# Yes". This could be worded, "Explicit language expression of when expensive boxing and unboxing routines have been invoked? Java Yes; C# No". This is what I meant above by '"mine is bigger than yours" bragging by fans', without the depth of coverage that would make the comparison useful to readers. For possible reader types, consider the project manager needing to decide which language to hire developers and develop a solution in, or the school-leaver deciding which language to study in depth to further their programming career. This article is too shallow and too detailed to help either of these. Who is it aimed at? Surely not just the egos of the Wikipedia authors who wrote it?! --Nigelj (talk) 17:21, 6 March 2011 (UTC)
Keep. If the threshold for inclusion in the article is the ability to cite reliable publications that explicitly compare C# and Java, then indeed the entire comparison category (e.g. file systems etc) would have go to away. No, the threshold to meet is that any claims must be verifiable. The language specifications are reliable sources as far as the syntax and semantics goes. Other sources must be used for e.g. history, philosophy. I also do not agree that this is "bragging". Does the article have issues? sure. We should fix them instead of deleting the article. This article is not stale; it still receives edits and it is read by visitors. Clearly keep. But let's fix the problems. Who is it aimed at? As is evident from the discussions above, there is obviously a lot of readers with experience from one language but without understanding of what/how the other is different. As the two languages are overlapping and competing in the marketspace it is and will continue to be a controversial topic; but also an interesting topic. Useerup (talk) 14:57, 9 March 2011 (UTC)
Strong Keep. The constant discussions, sometimes drifting into a flamewar, may be annoying. But this underlines how important the topic is to many people. This article is pretty much about the question why C# was made in the first place, even though it started off so close to Java. Vandroiy (talk) 20:54, 13 March 2011 (UTC)
Strong Keep. I think this is a very useful and informative article that can teach people something about both languages and their differences. There have been many discussions about what form the article should have and what content should be included by it, and there are definitely areas that can be improved, but that doesn't mean we should give up and delete the article. 82.210.112.192 (talk) 19:52, 15 March 2011 (UTC)
Strong Keep. I agree that the article doesn't use a clear method of comparison and that subjective statements are difficult to avoid, especially for contributors who only know one of the languages well. But I don't think this is inherent to the subject. Language features can be clearly separated from library features, and core library features can be distinguished from features in optional libraries. We just need to systematically qualify all statements about features with this information. For instance, statements such as "Java does not support events" or "Java supports events" are inadmissible, because they lack this qualification. Statements must also be qualified with language versions, if the feature in question is version-specific. For instance, "C# has special syntax to support events" is inadmissible. Won't doing this fix most of the problems? Rp (talk) 17:12, 16 March 2011 (UTC)
Weak delete. The article has some value and I don't mind if it stays, but it's impossible to give a realistic comparison of these languages without the corresponding discussion of frameworks and runtimes. Maghnus (talk) 10:53, 23 March 2011 (UTC)
Weak delete. However, I would not mind to keep this article, if only it really compared these two languages. As it is, it has become a feature-fest, not a comparison. I don't think that anybody can have an understanding of how these two languages are similar, and how they differ, by reading this. Only people already knowing Java of C# can really understand anything here. And I'm even not talking about the fact that there are so few references. Hervegirod (talk) 23:48, 24 March 2011 (UTC)
Strong Keep.
I followed both Java and then C# evolution, and this is no accident if there are more "features" in C#. C# evolves faster, whereas Java evolves slowly.
The reason could be justifiable prudence or unjustifiable laziness, or could be the justifiable need to keep it simple or the unjustifiable incapacity to make the language evolve, I don't care.
So the extra features could be useful, or useless, I don't care.
Let the reader decide if delegates, events, unsigned integral types, user-defined value types, operator overloading, etc. are a good thing or not, but don't remove the feature comparison just because you believe the feature is useless in your chosen language.
If you have any doubt about the usefulness of a feature, this Talk page is not the right forum to discuss it: Bring to issue to a developer's forum, http://www.stackoverflow.com for example, and compare the answers from the experts lurking there.
Paercebal (talk) 16:10, 23 April 2011 (UTC)
Edit
I removed the following content:
"Another criticism of checked exceptions is that a new implementation of a method may cause unanticipated checked exceptions to be thrown., which is a contract-breaking change. This can happen in methods implementing an interface that only declares limited exceptions, or when the underlying implementation of a method changes. To allow for such unanticipated exceptions to be thrown, some programmers simply declare the method can throw any type of exception ("throws Exception"), which defeats the purpose of checked exceptions."
This may not happen with checked exceptions. A checked exception must be declared in the public API of the method (throws clause) if you want to throw it. Therefore you may not throw a new type of checked exception unless you intentionally break the API, and this will not happen neither if you are just implementing an interface, nor change the method implementation (as it is not part of the API). --151.75.20.202 (talk) 13:20, 26 May 2011 (UTC)
- You could have added un instead of removing the whole section. So your reason for removing it must be something else. I'm not sure whether this discussion should be present. Is discussing the consequences of diffferences between the languages too far beyond the scope of this article? Rp (talk) 21:27, 27 May 2011 (UTC)
- Actually criticism in the section is specifically about checked exceptions. There is no contract-breaking change if you throw a different unchecked exception, as you are always allowed to throw any unchecked exception type from within any method, so the section just doesn't make sense if you add un. And, yes, maybe the appropriate place for that is Exception handling#Checked exceptions. --151.75.16.218 (talk) 00:15, 28 May 2011 (UTC)
Java unsigned integer type "char"?
I reverted an edit claiming that the Java char type is an "unsigned 16 bit integer" type. According to the language spec it is an integral type which as soon as it is used with a numeric operator (such as bitwise shift, -and and -or ) it gets promoted to an integer. So the char type is not an integer type, neither formally nor practically. It is a separate integral type which is convertible to integer but is itself not an integer. Please read chapter 5 of the Java Language Specification if in doubt. — Preceding unsigned comment added by 87.50.3.197 (talk) 21:23, 12 June 2011 (UTC)
Type system > Enumerations
I am a C# programmer and have been since version 1.0 of the language, but my intimate knowledge of the language may be incomplete. With that said, my understanding of enumerations is that they are type-safe. Also, as far as I know, C# is completely type-safe. It impossible, or near, to do something in C# that is not type-safe.
Enumerations do not derive from integer types (8, 16, 32, or 64-bit), but instead derive from System.Enum which in turn derives from System.ValueType, System.IComparable, System.IFormattable, and System.IConvertible. System.ValueType implicitly derives from System.Object. So, enumerations are value types, but do not derive from any explicit value type. When specifying an integral type for an enumeration, you're merely telling the compiler and runtime what the enumeration's numerical limits are; not deriving from the integral type. The idea of deriving from an integral type is an erroneous one because integral types are value types. Value types are implicitly sealed which means you cannot derive from them.
Enumerations only allow you to assign the enumeration's defined values. Integral values can be assigned to an enumerated type through casting, but this can lead to having values outside the implied range (the defined values) of the enumeration. An exception to this rule is the value of zero, which can be assigned to an enumerated type without casting.
It is true that enumerations don't allow anything other than the enumeration values. But, the Enum class defines four ToString methods which will convert any enumeration to a string without the need to define an explicit ToString method on an enumeration. The Enum class also defines several other methods which makes working with any enumeration easy.
So in short, I propose that the section on Enumerations be revised. I don't know enough about Java to do it in a non-biased manner.