Talk:Comparison of C Sharp and Java

From Wikipedia, the free encyclopedia

Contents

[edit] About benchmark restriction

"You may not publish or provide the results of any benchmark or comparison tests run on Software to any third party without the prior written consent of Sun."

Also MS came with some equal restriction.

The true is :

a ) CLUF, EULA and such form of software licensing are just a some prior advice rather a legal tools for protect the creator or copyrighted for the material and the use of it. But the truth is that the use is only a suggest, some sort "run and use and you own risk..", it's not mandatory or a legal contract that the current users must follow line by line. Most likely, this kind of message is to protect from any sue again them, it's not allow to the copyrighted can sue the final users in any means. For example sell the program or decompiler are protected by different laws (patent laws, copyright laws and local laws) not because this kind of "contract", but published a benchmark is not protected by any law.

I can put a CLUF that say : and everyone that use this software must be renamed 'BOB', of course i cannot force to anyone to apply it, even if the users in fact accepted this "contract" (really, nobody read the software licensing).

b ) To "accept" the download or the install a program is not a legal tools because it's inviable to apply, you cannot identify the actual installer.

c) Nor Java or .NET force you to sign a NDA (a true contract protecting to publish some information).

d ) Even if all of this was possible, you can install and check some benchmark/profiler and another people can publish it, this "third people" don't need to read the "contract" or even accept it, so he's free to publish the benchmark.



[edit] Primitive Types

The article states that Java primitive types also exist in C# and are known as value types, Accorging to http://msdn.microsoft.com/msdnmag/issues/1200/dotnet/ in the C# primitive types are int, string, long etc, i.e. a special type that can be used with a simplified syntax (e.g. int i = 5, rather than int i = new int (5)). Primitive types map to other c# types, so primitive type int maps to int32 (look at the msil). string maps to String etc. I.e. nothing to do with value/reference types.

I don't quite follow all your language here, but I think that your point is that in .NET "value type" and "primitive type" are not the same thing. I agree.
Leotohill 05:48, 8 November 2006 (UTC)
The way I understand it, all the primitive types are value types; string and object are not primitive types, but just C# aliases for String and Object. String is not a primitive according to the framework (check typeof(string).IsPrimitive). But I suppose you could call string a primitive in the *language* since it has a special constructor syntax, if you have a good (better) reference for that. - Chip Zero 17:48, 8 November 2006 (UTC)

[edit] Contradictions Between Articles

There's a significant and obvious contradiction between the C# vs Java article and the main C# article, specifically, about garbage-collection. The main article states, "A common misbelief is that they are garbage-collected, though they are not; they are true value-types and are stack allocated (with an exception for System.Object, and due to interning, System.String)." while this article begins, "As two modern garbage-collected runtime-compiled languages derived from C and C++, Java and C# are very similar."

I'm not familiar enough with the language to fix this myself, but wanted to note it for others to take a look at.

Cross-posted to the main C# talk page.

>> This is generally accurate. Value types are not garbage collected per se, but reference types in the language are heap allocated and are subject to garbage collection.

[edit] General discussion and enums

How does Java have a simpler language? The CLR has some JIT time optimizations as well as runtime optimizations. Java and C# run at about the same speed really. It might not be true that Java is faster.

The article needs to be cleaned a bit... Some entries are listed as both advantages for one language and disadvantages for the other, which is at best redundant. Otherwise, it's not bad; quite complete now. GregorB 22:49, Jan 31, 2005 (UTC)

I think there is good reason for pointers to be listed as both an advantage and a disadvantage for C#. I don't think there exists enough consensus about whether pointers should be used in managed languages. It might be appropriate to go into more detail about how pointers are implemented with relative safety in C# on another page and then link it. Tbjablin 05:36, 8 Feb 2005 (UTC)

I've decided it belongs in differences after all. Tbjablin 05:44, 8 Feb 2005 (UTC)

  • Both languages allow the use of enumerations, via the enum keyword.

As far as I recall, this is false. C# uses the enum keyword, whereas Java uses a Class (link java.lang.Enum) introduced in Java 1.5. I haven't edited the page to reflect this, as I am unsure and would like confirmation first.

In Java 5.0 enums are lower case, like types, and have their own syntax.

 private enum Coin {
   penny(1), nickel(5), dime(10), quarter(25);
   Coin(int value) { this.value = value; }
   private final int value;
   public int value() { return value; }
 }

Also enums can be used in switches. Classes cannot be used this way.

 switch(menu) {
   case FILE:
     System.out.println("FILE Menu");
     break;
   case EDIT:
     System.out.println("EDIT Menu");
     break;
   case FORMAT:
     System.out.println("FORMAT Menu");
     break;
   case VIEW:
     System.out.println("VIEW Menu");
     break;
}

Check out http://java.sun.com/developer/technicalArticles/releases/j2se15langfeat/ http://zamples.com/JspExplorer/samples/jdk1_5.jsp http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

In Java even arrays are technically classes ie

   Object o = new int[10];

same in c# --Motherofinvention 01:05, 29 June 2006 (UTC) Further compiling:

   public class Test {
       private int enum = 10;
   }

Yields the error:

   Test.java:2: as of release 1.5, 'enum' is a keyword, and may not be used as an identifier
   (try -source 1.4 or lower to use 'enum' as an identifier)
       private int enum = 10;
                   ^
   1 error

My inclination is to call it a keyword, because of the new syntax, and the compiler error. Tbjablin 04:34, 9 Mar 2005 (UTC)

Yeah, it seems pretty clear that enum is a keyword in Java. Neilc 01:08, 10 Mar 2005 (UTC)

Keyword or not, enum is a feature of all (or nearly all?) programming languages in the C language family, and as such is uninteresting in this context. I've deleted the reference, hope that's OK... GregorB 12:37, Apr 29, 2005 (UTC)

[edit] Virtual machine?

C# is compiled to MSIL which is compiled into native machine code; Java is compiled into .class files which are interpreted by the JVM. The article says they both run on a virtual machine, but C# does not. I ran a series of benchmarks which I posted here and am quite sure that C# is appreciably faster than Java.

Both C# and Java use JIT compilation. Java can run in interpretted mode and even has a flag for it java -Xint, but java -Xmixed (interpretted mode mixed with compilation) is the default. You might want to try rerunning your benchmark with java -server -Xincgc -Xmx512M and Java 1.5 Tbjablin 01:25, 24 Apr 2005 (UTC)

Also, looking at your benchmarks they are quite clearly dominated by Java's slow startup time. You might consider benchmarks that run for atleast a minute. Compare your results with [[1]] at that time Java was outprerforming C# in every area except trig performance, but things may have changed since then. Tbjablin 01:33, 24 Apr 2005 (UTC)

So I tried to repeat your benchmark. Here's what I found:

   cat Test.java
   public class Test {
       public static void main(String[] args) {
           long time = System.currentTimeMillis();
           for(int i = 1; i < 1000000000; i++) {
           }
           System.out.println((System.currentTimeMillis() - time));
       }
   }  
   java -hotspot Test
   1612
   java -server Test
   3

Tbjablin 03:05, 24 Apr 2005 (UTC)

[edit] Event Handling?

I'm not sure if your observation is correct about event handling. In java one ActionListener can listen to many different UI elements. I think that the net result is the same as in C#, and that the difference is really semantic. Tbjablin 02:28, 24 Apr 2005 (UTC)

I think this link supports my point: [[2]]


--Agreed, the only difference between the use of event handling in Java vs C# is simply an overloaded operator. --capnmidnight

I have to put back at least initial sentence. I left out the other junk about it streamlining code and running faster (I totally support this omission). However, I think it is an (arguably) advantage--albeit minor-- that event is a C# keyword. If you edit this, at the very least just remove it from "advantages". It is certainly a valid difference. -- Chris 03:14, 29 August 2005 (UTC)

[edit] Method invocation of Java is simpler than C#?

The article states about Java: "Method invocation model is simpler, making it easier to implement and at times easier to read."

Maybe it's just me, but I don't see the difference between
javaObject.methodCall()
and
csharpObject.methodCall()

Am I missing something? Maybe you are talking about the "best practice" of capitalizing method names. This is not a feature of C# any more than creating meaningful variable names, or using for loops instead of while loops, i.e. it's up to programmer preference.


"C# includes delegates, whereas Java does not. Some argue that delegates are extremely useful, but others point out that their inclusion complicates the method invocation model." This is what that line was refering to. I didn't understand it when I read it either, so I changed it. Hopefully, it is clearer now. Tbjablin 05:02, 24 Apr 2005 (UTC)

What do you understand by "method invocation model"? Is it compile-time or run-time? If you say compile-time, I agree, the same syntax/grammar is used to call a delegate and to call a single method. If you say run-time, I disagree, because by then it will either iterate the delegate OR call the method, it won't decide which to do at run-time because that's already hard-coded. So, you MUST clear which do you mean, compile-time or run-time. I suggest renaming it to "method invocation syntax", assuming compile-time since in run-time it's nonsense to say it's simpler in Java.
Did you read the link at the bottom of the discussion? [3] The author has evidence that delegates use relfection implicitly, and that they are not simply pointers to functions. If you can produce some disassembly that disagrees with his results, or can explain his results, I would be very interested.
I did, and i'm sure this is wrong. I posted the following answer on that page. since it was not instantly published, i repeat it here: "delegates expose reflection members as a convenience, but do not use reflection for actually invoking the delegate. how do i know? the performance penalty for using delegates is a factor of circa 1.1, while using reflection gets you a factor of about 100!
also, the observation of Brian are not attributed correctly. since structs (value types) are usually copied rather then referenced, the delegate operates on a copy, which cannot reflect subsequent changes in the original object. this is perfectly consistent with the value type semantics in c#. additional rationale: consider creating a value type object on the stack and then creating a delegate on it. the delegate might survive the deletion of the object (stack unwind) and therefore would point to an invalid memory address."
The remark about reflection should therefore be removed. --Motherofinvention 01:05, 29 June 2006 (UTC)

--In that case, delegates don't complicate the model, they expand the model. One can completely ignore delegates and still be a quite succesful coder in C#. I think it gives a false impression that C# is more difficult to learn than Java. While it will certainly take you longer to learn completely (since there are more language-level features in C#), base functionality in both languages is a nearly identical task.

If anything, if we define a task T that is particularly suited to being implemented with a delegate pattern, then Java is technically more complicated. One would have to use a lot of interfaces, annonymous inner classes, and the Reflection API to achieve all the same things that delegates achieve very easily. I shudder to think of the ugly hack that would result from trying to reimplement delegate concatenation in Java.

This is the same arguement that C zealots make against C++, that C++'s inclusion of additional keywords made it a more complicated, and more difficult to learn. It's just not true, more language features make languages easier. We invent new langauges to make our jobs as programmers easier, not to make them more difficult. Imagine if your speaking vocabulary were cut in half, would you be able to express yourself as easily?

Delegates are there if you know how to use them, and they sit out of the way if you don't. They're not there at all in Java, so even if you know how to use them, you're out of luck. --capn_midnight

I think the criticism is that determining which method is actually called at run-time more complicated, and can incur a performance hit. Check this out [4], but I guess all OO features are more complicated than just calling static function. Tbjablin 13:16, 25 Apr 2005 (UTC)

[edit] Switching Strings

Just throwing a question out there: should we mention that C# allows for strings to be used in switch statements? It is a minor feature, but it is a difference. Does Java have this yet? DoomBringer 08:12, 8 May 2005 (UTC)

Java does not support switching on strings. It seems like a minor feature to me though. Also, does C# support just switching on Strings, or switching on all Objects? Tbjablin 13:26, 8 May 2005 (UTC)
C# Language Specification lists "possible governing types" of a switch statement as: sbyte, byte, short, ushort, int, uint, long, ulong, char, string. Switching on strings would thus be the only difference compared to Java. Not a groundbreaking feature, but it's very useful nonetheless... GregorB 11:13, May 9, 2005 (UTC)
I would say that it is a noteworthy feature. Any neato feature like that prevents me from doing a huge if-elseif-... construct, which can get ugly. The claim was made that switching on a string in C# isn't as horrible for performance as some would think, but I don't know the underlying implementation, so I can't say for sure. I just know that I like being able to switch on strings. DoomBringer 07:09, 18 May 2005 (UTC)
c# uses string interning, meaning that strings used in switch statements are included in some global hashtable and then compared based on their references (which are primitives), not their value. it's therefore the same as a switch using primitive value, except for the initial effort of interning.--Motherofinvention 01:05, 29 June 2006 (UTC)

I've added it, since no one had any issues here. If you feel otherwise, post something here first.

[edit] ROTOR mention?

Should we mention the ROTOR implementation of the CLI? You can run .NET code on BSD Unix (I think), and it is "shared source". It isn't a feasible enterprise solution, as I think the license prohibits it, IIRC. DoomBringer 07:14, 18 May 2005 (UTC)

No, ROTOR is completely seperate from the C# language spec. This is about comparing C# to Java, not about comparing the CLR to the JRE. capnmidnight 16:26, 30 April 2006 (UTC)
Rotor does include the source code of a C# compiler though. doesn't this deserve mentioning? --Motherofinvention 01:05, 29 June 2006 (UTC)

[edit] Call by reference

Note that call by reference doesn't apply just to primitive types, as it might seem at first sight. Variables in Java which are not of primitive types hold a reference to an instance, and since all method calls pass arguments by value, the reference held by the variable is passed, since that is the value of the variable. But imagine you want the variable to "point" to another instance after the method returns; then you have to pass a reference to the variable itself, not the reference the variable holds.

A non-pragmatic but straight example in C#:

void ChangeVariable(ref string s) {
 s = "-+" + s + "+-";
}

void SeeChange() {
 string s = "Test";
 ChangeVariable(ref s);
 Console.WriteLine(s);
}

Output:

-+Test+-

I see your point. Perhaps a better example is:

void ChangeVariable(ref string s) {
 s = "Test";
}

void SeeChange() {
 string s;
 ChangeVariable(ref s);
 Console.WriteLine(s);
}

The point is that Java lacks what would be "<class_type>** name" style pointers to pointers in C++. Tbjablin July 3, 2005 04:48 (UTC)

[edit] 'Enormous and highly active user base'? NPOV ... need numbers vs C#

This language is not neutral, is vague, and does not go toward the point of the article. If the user base is 'enormous' and 'highly active', it must be assumed that this is in contrast to that of C#. Does anyone have a citation?

Measuring the user base of a language is incredibly hard. You can look at the number of published C# books versus the number of Java books on Amazon. So "Java language" yields 2k hits versus 400 hits for "C# language." Alternatively if you look at Google hits for the same query its 29M hits versus 3M hits. MSN shows 36M hits versus 250K hits. Sourceforge records 16K Java projects and 2.5k C# projects. All of these samples are subject to error and source bias, but they all seem to indicate that the number of Java developers is substantially larger than the number of C# developers. The statement is somewhat vague because although no one knows the real numbers, we can still make comparisons between the two user bases. The point of the article is a comparison of C# and Java. One of the ways that the languages differ is that Java seems to have a greater mindshare. Tbjablin

All good points. And I like your 'large' change. Thanks for the response. -- Chris 18:58, 2 August 2005 (UTC)

[edit] Speed comparison in Java SE 5.0 and .NET 2003

C# is a bit faster then Java and significant faster in nested loops (like matrix multiplication). Also, GUI might be much faster in C# then in Java. Performance comparison C++, C# and Java LZMA implementation speed comparison

I think this piece of text needs significant revision, and may not be appropriate to the article. The basic premise of the first sentence is that C# is faster than Java in nested loops, but this is contradicted by both of the links the author provides. Furthermore, the links appear to be microbenchmarks, the results of which are frequently not born out in more detailed studies. These tests can be dramatically influenced by how many times a compiler unrolls a tight loop. Also, the first benchmark is of the hotspot client vm, which is much slower than the server version for many tasks. What exactly is the comparative performance of two languages? Basically, any sort of comparison will be between particular compilers, particular VMs, and particular machines. The language itself doesn't enter into the equation. If we are going to make a comparison between Java and C# based on performance it should be well-researched position. It would talk about what specific parts of Java or C# effect performance, based on results that are repeatable, significant, and generalizable across the range of supported platforms. For example: Java's floating point implementation is slower than C#'s because Java guarantees the results of floating point calculations across platforms and therefore does not use special hardware. The second sentence appears to be speculation. Tbjablin 07:12, 17 August 2005 (UTC)

[edit] Major Reorganization

I just made a big change to the article, in response to concerns raised on the AFD page. Most of the facts in the original article were kept, but their order and sometimes their wording was changed. In some cases two bullets were merged. Please flame me under this heading if you do not like it. Tbjablin 00:25, 19 October 2005 (UTC)

[edit] AfD result

Articles for deletion This article was nominated for deletion on October 18, 2005. The result of the discussion was keep.

— JIP | Talk 10:32, 25 October 2005 (UTC)

[edit] Changed name from Comparison of C Sharp to Java

Changed name to use more neutral language. – Doug Bell talk•contrib 05:10, 6 March 2006 (UTC)

[edit] Cleanup tags

I've tagged this page with three cleanup tags: advert, importance, and tone.

  • Advert: This article has a strong pro-C# bias.
  • Importance: What information does this article provide that is not available in C Sharp or Java programming language?
  • Tone: Most encyclopedias avoid direct comparisons of subjects, and for good reason. Rather than a prosaic discussion of fundamental differences, this page seems to provide large bulleted lists of features of dubious importance.

—donhalcon╤ 05:38, 6 March 2006 (UTC)


  • Advert: Does the page really have a C# bias? I think it is a neutral fact that C# has more features than Java. Whether or not more is better and whether the features are actually useful is left to the reader.
  • Importance: I'm willing to concede that the article contains no information not found in C Sharp or Java programming language, but that's true of all comparison articles.
  • Tone: The article is more encylopedic than Comparison_of_browsers, but that isn't setting the bar particularly high. It's substantially similar to Comparison of Java and C++, which I see you've also marked for cleanup. I suppose we might look to Abrahamic religion as an alternative model.
I think it might be a worthwhile experiment to convert parts of the article to prose. Maybe over the weekend if I have time. Tbjablin 05:34, 7 March 2006 (UTC)
I think I'm going to AfD "Comparison of web browsers" soon, so that bar is a bit too low. Abrahamic religion is a good model; a page already exists with that potential for this article and Java/C++ at curly bracket programming languages, so maybe we could merge some of this content over there. Comparative content has potential, it just needs to be encyclopedic — and preferably more concise that one article per possible pair of languages. —donhalcon╤ 05:56, 7 March 2006 (UTC)
If Comparison of Web Browsers then why not Comparison of linux distributions or Comparison of operating systems. I think there exists an unwritten policy that comparison type article are held to a different standard. List of countries by GDP (PPP) is a really a comparison article too. I think that for a certain class of articles a gazeteer type standard of quality is more appropriate and consistant with the defacto standard. Tbjablin 06:52, 7 March 2006 (UTC)
Actually to be consistant you should AFD everything in [5], some of those articles have less prose than Comparison of web browsers. Tbjablin 06:55, 7 March 2006 (UTC)
There is no unwritten policy that says that Wikipedia policies don't apply to certain articles; lists have historically been accepted as a way to index the encyclopedia, not as a separate space for content (WP:NOT deals with indiscriminate lists explicitly). I don't believe that poor quality should be excused in an encyclopedia article just because it doesn't belong in an encyclopedia in the first place.
I already did (successfully) AfD list of multi-threading libraries, which was strikingly similar to comparison of web browsers; I will almost certainly AfD the other unencyclopedic lists you've mentioned and many others as I work to clean up Category:Comparisons. I've already tagged a significant fraction of Category:Programming language comparison for cleanup and fully intend to AfD anything in it that can't be turned into content that belongs in an encyclopedia. The tags are there to let people know that the articles either need some serious work to reach encyclopedic quality, or need to be merged out to the articles where their content actually belongs — I have nothing against including the content, it just needs to meet basic standards of quality, and it needs to be in an appropriate location. —donhalcon╤ 07:17, 7 March 2006 (UTC)
I've looked at list of multi-threading libraries and I think it was at all similar to comparison of web browsers. I think you should AFD comparison of web browsers immediately, because it will provide useful precedent for what is or is not considered a quality list. WP:NOT does deal directly with the subject of indiscriminate lists, but I don't think that these comparisons fall under that clause, but I could be wrong. If Comparison of web browsers dies in AFD then we should add a new clause to WP:NOT specifically damning non-prosaic technical comparisons. Tbjablin 07:54, 7 March 2006 (UTC)
I'm in the process of listing it now, but I don't think that result will necessarily set any kind of precedent, nor would its deletion entail revisions to existing policy — WP:NOT already excludes indiscriminate collections, FAQs, instruction manuals, and original research, which I think are sufficient to cover a large portion of Category:Comparisons. —donhalcon╤ 14:46, 7 March 2006 (UTC)
Which of those items (indiscriminate collections, FAQs, instruction manuals, or original research) do you think comparison of web browsers is? Tbjablin 20:33, 7 March 2006 (UTC)
That's fairly irrelevant here, considering that this is the talk page for Comparison of C Sharp and Java. —donhalcon╤ 20:47, 7 March 2006 (UTC)
I think the consensus that is forming at Wikipedia:Articles_for_deletion/Comparison_of_web_browsers and Wikipedia:Articles_for_deletion/Comparison_of_Internet_forum_software would be relevant for nearly all the pages in Category:Comparisons. Tbjablin 20:54, 7 March 2006 (UTC)
Could be, but even if they still exist they still need to meet the same standards of quality as the rest of the encyclopedia. —donhalcon╤ 21:15, 7 March 2006 (UTC)
I agree generally with a lot of these points. It's not that bullet pointed lists aren't useful, but rather this article has a bit too many of them. I think "Differences in maturity" can be kept largely as is, and "Philosophical differences" could be kept as the only list in the article (with some 'too specific' points merged or dropped). The opening lists should be replaced by prose, with all minor nitty-gritty differences dropped in favour of a more general discussion of how the intended audience/market of each language has shaped its development. The article should probably be headed by a short section on the 'supposed' rivalry between the Java and C# camps (which is, after all, probably the real reason why the article exists.) JavaKid 17:49, 10 March 2006 (UTC)
As to the "importance" tag, the first paragraph of the article states the importance. As well, examining importance, this article passes every piece of important criteria, not just the one as is required to pass the test of "importance". - Chris 21:33, 10 March 2006 (UTC)
OK, I've removed both the {{advert}} and the {{importance}} tags. I addressed the importance above. As for the "advert", I suppose that's subjective, but the article seems as NPOV as possible. It may fall under {{tone}}, but I still think it's totally fact-based and written quite formally. - Chris 21:38, 10 March 2006 (UTC)
I've broken the ice by posting a quick first draft of a prose-based discussion which avoids listing features. (Hope this is okay?) It instead looks at the historic rivalry between the two camps (which I personally think is overplayed - I don't see many attacks in their community on the other these days - but that's just my POV). I've then added a breakdown of the various markets in which Java and C# might compete, presently and in the future. I've left the bullet point lists in for now - but at some point they should be zapped IMHO. This stuff needs some C# details urgently, to add balance. It would also be nice to get some citations and supporting material for the two 'theories' as to C#'s political (or not) origins. Feel free to add/rewrite/shred this new material if it doesn't meet the 'tone' requirements. JavaKid 19:41, 11 March 2006 (UTC)
Actually I thought has occured to me that my material perhaps strays a little too much towards comparing the API's and frameworks associated with each language. Problem is, the only way to compare any two languages without resorting to a list of features is to consider their history, rivalry, 'culture' and 'environment' - which inevitably brings in material about associated APIs, frameworks and usage. JavaKid 19:52, 11 March 2006 (UTC)

[edit] What is the language API?

The article states that "The C# API is completely controlled by Microsoft, whereas the Java API is managed through an open community process." I can't figure out what "API" means in this context. Seems like the wrong term to me.

I think that in this context "API = language specification" , but if so then this sentence is just a restatement of one that preceded it. Leotohill 02:53, 30 May 2006 (UTC)

Now I've removed the objectionable sentence. Leotohill 19:11, 30 May 2006 (UTC)


[edit] Differences Rearrangement

I think the structure of the article needs to be cleaned up. There are many different sections talking about differences. The "language design differences" is very similar to the generic "differences" section above, and to most readers they wouldn't understand the distinction. I think this stuff needs to be moved around to flow a little more logically. Thoughts? Gaijin42 12:33, 14 June 2006 (UTC)


[edit] Simplicity

section "differences" states that "C# language has many more features than Java. Whereas Java keeps things simple."

first, this would be better suited at the top of the list, since it's more general then the points after it. second, i would consider the conflict between "keeping the language simple" and "keeping the code simple", advocates of the latter arguing that advanced language constructs enable simpler coding of certain patterns. a NPOV description of this conflict would reduce the need for philosophically discussing every single such design decision (delegates...). i can make that change, but i might be too biased towards c#. --Motherofinvention 01:05, 29 June 2006 (UTC)

[edit] problem-specific features in c#

it's not true that c# 3.0 has SQL or XML specific enhancements. 3.0 brings a lot of general enhancements like lambda expressions, type inferencing, extension methods, passing expressions as object trees (rather than compiling them) and others. none of these are specific to SQL or queries. using these features, one can create queries among other things:

datasource.Select (x => x.Name).Where (x => x.Age > 20)

additionally, c# 3.0 offers a syntax that is specific to queries and is somewhat similar to SQL or XQuery:

from x in datasource select x.Name where x.Age 20

The latter expression is translated to the first one and then compiled. therefore, only a (rather small) fraction of the new syntax is directly aimed at queries, while the larger part is of general usefulness. the syntax is always the same, only the type of 'datasource' determines whether the code is compiled (resulting in delegates being invoked while the main methods - select and where - iterate over the collection) or an expression tree is created and passed to the methods. which one is used depends on the argument types the datasource's methods declare (F<T> or F<Expr<T>>). so, there IS a query-specific part to c# 3.0, although the extent of this part is overestimated. however, there IS NO syntax specific to either SQL or XML. --Motherofinvention 01:05, 29 June 2006 (UTC)

Yes -- I just noticed the same thing. I took a stab at alternate language that I think is more correct. I have very little experience editing Wikipedia, so I apologize if I did anything wrong. --Strangeweather

[edit] native code invocation

the discussion fails to mention two important points:

1) in addition to calling functions via P/Invoke, C# can also interact with COM objects using "COM Interop". (both ways, involves compile-time code generation though.)

2) JNI requires specially crafted native methods. P/Invoke can call virtually any existing method in any DLL that uses standard Windows calling conventions. --Motherofinvention 01:05, 29 June 2006 (UTC)

[edit] Rivalry edits

I removed the paragraph that began "It is a frequently held charge that C# was created out of a political motivation by Microsoft,..."

Microsoft has been accused of many things, but I don't think that pursuing "political" (whatever that means here) vs. economic motives has been successfully argued. I first tried to rewrite the paragraph without using that word, but could not succeed with any cogent statement. If I write that "...C# was created out of economic motivation..." the reader will think "well, duh".

I did incorporate some of the phrasing into another existing paragraph.

Leotohill 01:41, 29 June 2006 (UTC)

[edit] Delegates

Removed the second and third sentences from this:

C# includes delegates, whereas Java does not. Some argue that delegates complicate the method invocation model, because they are handled through reflection, which is generally slow. On the other hand, they can simplify the code by removing the need to declare new (possibly anonymous) classes to hook to events.

First of all, the second sentence is a non sequitur. Making things slower does not complicate them, so the "because" is faulty. It could be "and", but then we still haven't explained why they complicate the method invocation model. Invoking a delegate is no more or less complicated than invoking a method on a class instance; the difference is that the instance is determined at run time. You could call this a "complication", but then event handling in general is a complication.

Second, the assertion that "delegates are handled through reflection" is either false or misleading. Can we have a source for this (as in, a direct reference, not an external link)? In particular, creating a delegate to a function and invoking it normally does not involve any reflection, which is good, since otherwise every single event would involve (horrendously slow) reflection!

Third, the last sentence, while factually correct, is also misleading. In C# (pre-2.0) you have to declare a new method for every event handler (and there's no such thing as an "anonymous method"), while in Java, you have to declare a new class, but you can use anonymous classes. Whether either is simpler is debatable. In C# 2.0, you can use anonymous delegates, which do simplify things in a sense, since you don't have to declare anything anymore except the function body. 194.151.6.67 13:10, 4 July 2006 (UTC)

I had the same concerns - glad you made the edit. I believe that the use of delegates does require reflection, because the necessary information is not known at compile time. However, the reflection is required only once, when the delegate is instantiated. As long as the delegate instance remains, it and the underlying method can be repeatedly invoked with no more overhead than a typical method call (because at that point, it 'is' a typical method call. ) Bottom line: the cost of the reflection required for the delegate feature can be negligable, depending on how it is used.

Leotohill 15:41, 4 July 2006 (UTC)

does creating delegates involve some kind of access to internal reflection data? maybe, even typeof() does. however, typeof is much faster than creating delegates. why? probably because a delegate is a reference object which actually needs to be created on the heap and garbage collected at some time.
here's what i measured for invoking a static method (or creating the delegate/method info) 10,000,000 times. (release build without debugging, direct invocation is sometimes too fast for the measuring threshold of ~15 msec):
Direct invocation of f0                                  0,00 msec      0 GCs
Delegate creation of f0                                250,00 msec   1952 GCs
Delegate invocation of f0                               62,50 msec      0 GCs
Delegate creation and invocation of f0                 296,88 msec   1953 GCs
Reflection creation of f0                            6.297,00 msec   4638 GCs
Reflection invocation of f0                         11.937,73 msec      0 GCs
Reflection creation and invocation of f0            21.687,92 msec   5615 GCs
i think the duration of 250ms is perfectly attributable to creating 10 million objects and performing almost 2000 garbage collections. --Motherofinvention 09:46, 5 July 2006 (UTC)
Mother, could you post your source code? You could just paste it into my talk page.
Leotohill 16:22, 5 July 2006 (UTC)
I'm on vacation, I'll have access to the code again in 2 weeks. However, I'll probably forget to post them, so feel free to email me in two weeks at senor.cortez@gmx.at --Motherofinvention 20:54, 7 August 2006 (UTC)

I'd like to point out that benchmarks are a weak indication of what's happening under the hood. In particular, directly invoking a method will always be faster than doing it indirectly, no matter what mechanism you use. And note that there's more than one way to create and invoke a delegate: doing it fully dynamically will involve reflection, but this is not the common case.

More to the point, I think we're straying off-topic. This has little to do with comparing C# to Java—if events are implemented through delegates and delegates should use reflection, who cares? There's no way this'll show that handling events in C# is inherently slower or more complicated than in Java. Basically, the difference is that C# has delegates and Java doesn't, and that event handling is therefore implemented differently. The answer to whether either is superior to the other is "probably not". 194.151.6.67 11:49, 10 July 2006 (UTC)

I just replied to the remark that delegates are implemeted via reflection and, since reflection is slow, therefore delegates have to be slow. I don't know how anybody could write up such conclusions without once having it occur to them to just measure the performance of delegates, but that's what happend and an answer was due.
As for the original goal of comparing C# to Java: If delegates really were slow, it would be just fair to point out that the power of delegates comes with a price tag. Since this is not the case, it's irrelevant.
Superiority is always hard to claim, but anybody who has either witnessed the complexity of interface overuse or the power coming from functional languages will agree that delegates are a very important difference between c# and java. It's more than just not having to hand-code the observer pattern again and again (or depending on code generators). It's a whole new game, especially with closures (c# 2.0) and the lambda operator (c# 3.0). Read about higher-order functions in Functional programming.
In conclusion, I think it's a valid statement that if two languages are completely identical otherwise, the one featuring higher-order functions is superior. They are a very powerful abstraction. But I'm straying again ;-) --Motherofinvention 20:54, 7 August 2006 (UTC)
Neat, lambda's are coming to c# 3.0? When is it coming out? --gatoatigrado 04:08, 7 September 2006 (UTC)

[edit] reorganization

This is why I reorganized some things. Feel free to discuss here. --gatoatigrado 04:56, 7 September 2006 (UTC)

[edit] removed similarities / differences

This gives the article a less competitive and more intellectual appeal --gatoatigrado 04:56, 7 September 2006 (UTC)

[edit] removed bullets

This may refocus the article on content and not competition --gatoatigrado 04:56, 7 September 2006 (UTC)

[edit] added features table

It makes it easier to see some of the neat innovations. Although it appears to contradict my goal of removing competitive aspects of this article, I think it's useful to have a table of the aliases for things which aren't major language features, such as "using", which merely forces a dispose on an IDisposable object. --gatoatigrado 04:56, 7 September 2006 (UTC)

[edit] what needs to be done

Please add other suggestions or summaries of what you have changed here. I think that by reorganizing things, repetitive information is now closer together as it should be, and hopefully can be removed. --gatoatigrado 04:56, 7 September 2006 (UTC)


Another thing - perhaps I shouldn't have removed the tone tag, it does need some things converted to more grammatically correct or interesting prose. --gatoatigrado 04:57, 7 September 2006 (UTC)


Certain headers may need to be reorganized; perhaps "event handling" should not be a subheading of "notation", as it is much more than a little language construct. It would make it look better from an "english" standpoint if text under headings was longer (either more information or less headings). --gatoatigrado 05:15, 7 September 2006 (UTC)

[edit] Virtual methods

Someone added the claim that "Compilers can easily detect whether a virtual method is not really a virtual method and treat it like a non-virtual method.". I don't see how this can be. Consider the class hierarchy

  A
    B subclass of A

and a third unrelated class that defines the method foo:

  foo(A parmA)
  {
     parmA.DoSomething();
  }


On any particular call to foo, parmA could be an instance of A, or it could be an instance of B. The compiler cannot determine whether DoSomething() is a call to a method on A, or to an override of it on B. That can only be determined at runtime.

I'm inclined to remove the claim. Leotohill 04:13, 7 November 2006 (UTC)

Aside from explicitly declaring classes and/or individual methods final or sealed, which pretty much implies non-virtualness, there's also the case of static analysis. In particular, if foo as defined above is private, and the actual type of object referenced by parmA in all code paths containing the invocation of foo can be proved to always be A, the compiler could go ahead and make the call to DoSomething() non-virtual (or even inline all invocations to foo, and remove the method body completely).Of course, this optimization only covers a small subset of all cases, and in general, there's no way the compiler could correctly deduce virtualness of method in an open system. -- int19h 07:06, 7 November 2006 (UTC)
I think with your revision it describes the performance overhead quite accurately again. But perhaps it should be mentioned that the C# team didn't just choose non-virtual by default for performance reasons, but also out of versioning concerns [6] - Chip Zero 16:21, 7 November 2006 (UTC)

[edit] Standardization

I modified some part of this chapter, as a lot of it was incorrect or POV : as for the relationship between Microsoft and the community, the deal with Novell does not mean that Microsoft would not want to sue other competitors (recent declarations of Steve Ballmer about Linux infringements on Microsoft patents rather say the contrary, and look at one excerpt of the referenced article : As part of the agreement, Novell will pay a running royalty to Microsoft for use of its patents in SUSE Linux); as for Java, Sun has no veto on Java modifications, it is governed by the JCP, and one could not say that Java is not standardized, only that it is not standardized by a ISO or ECMA standard; as for licensing, I separated this part from Standardization, and changed or deleted POV sentences, as the paragraph almost said that Java was not open-sourced, even after the GPL declaration. Hervegirod 19:16, 19 November 2006 (UTC)

Microsoft has agreed not to sue Mono or any project included in Suse. The deal is with Novell, but the specific projects and their maintainers are protected, and the software can be used and distributed by anyone.
Sun specifically does have veto power over the Java platform, it's a formalized right that Sun included when defining the community process. The "veto" right is a specific formalized action that Sun can take to block anything/everything they please.
Java has specifically not been standardized, it hasn't even been legally authorized for third-party implementation or compatibility. If I'm wrong, where are the standards? What standards body is distributing them? Where is the formalized reference material on Java? Sun isn't distributing anything that's comparable to the work of a real standards body, and a proprietor documenting its proprietary system is NOT standardizing, anyway. No one is calling .NET a standard because of Msdn documentation, it's a standard because third-party standards bodies have formalized it and made those standards legally and literally available to the community. The JCP is only a way for third parties to add to Java, the way a third party can ask (pay) Microsoft to add something to the next version of Windows or DirectX.
That's a rather strange definition of a standard. There's nothing special about "real standard bodies" - they're just organisations that publish standards. In case of Java, so does Sun. We have a formal language specification, a bytecode specification, and a set of documented APIs. Anyone who is implementing those is, in effect, implementing Java (setting the trademark issue aside), on which any existing Java code can run just as well as it would on Sun's reference implementation. Sounds pretty standardized to me. -- int19h 07:14, 20 November 2006 (UTC)
There IS something special about real standards bodies: standards so published cannot be revised without the agreement of that body. The bylaws of the organization determine the procedure for revision, and it usually involves committees, a public review, and votes by qualified members. The JCP is not the same - at any time Sun could revise the Java spec without consideration of the JCP, or could refuse a recommendation of the JCP. Leotohill 16:40, 20 November 2006 (UTC)
Right, it seems that we have a disagreement on terminology here. Nothing wrong, though - have a look at the definition of open standard on Wikipedia: "There is little really universal agreement about the usage of either of the terms "open" or "standard". Some people restrict their use of the term "open" to royalty-free technologies, while others do not; and some people restrict their use of the term "standard" to technologies approved by formalized committees that are open to participation by all interested parties and operate on a consensus basis, while others do not." Since Wikipedia itself does not give a definite meaning to the word, I'm not sure what to do here... could we say that Java is "considered an open standard by some, but not all, definitions of the latter"? -- int19h 07:10, 21 November 2006 (UTC)
I've just written a file exchange program, and written a .txt file about the custom protocol. I guess it's a standard now. (laugh)
Sun refers to their literature as "specifications", so why don't we use that word? Personally, what I object to is any suggestion that Sun can document Java and somehow achieve something comparable to going through the ISO. Keep in mind that Microsoft has thoroughly documented their non-standard .NET extensions on MSDN, so if Java has been "standardized", so has all of .NET. We do need some way to distinguish between the Ecma/ISO parts, and the MSDN-based parts, and it boils down to standardization vs specifications, even if the comparison that none of Java has been standardized is uncomfortable for some. - 70.69.42.228
The text you've quoted from open standard could serve to narrow the definition of what is "open", and so strengthens the position that the Java standard is not open. In any case, that text is a small prelude to the common definitions that follow, which I believe support the position that ISO/ECMA standards are open, and Java is not. Leotohill 20:35, 21 November 2006 (UTC)
One of the most important aspects of a standards organization is that its process is neutral to all members of the community. That's why passing off C# and the CLR to Ecma and the ISO was so important: neutrality. You don't really have a standard at all, by definition, if one member of the community has disproportionate and arbitrary control over the "standard". That defies the basic point of a standard. For instance, Microsoft's MSDN has documented many Windows platform specifics, but there are still some vital differences between a neutral standard like POSIX, and the Windows API, or W3 specs, and IE documentation. We don't count vendor literature as a standard for a reason, and Sun is no exception. - 70.69.42.228
Java is currently NOT free software. The "GPL declaration" is an announcement of intent. I've added refs to Sun's current JRE license, and it's not the GPL. This may change in the future, but for now, repeat after me: JAVA IS CURRENTLY NOT FREE SOFTWARE. If I'm wrong, add a ref to a release of Sun's full working JRE under the GPL. If you can't do that, stop censoring the facts.
The whole issue is not quite as simple as that. First and foremost, "Java" is a language. JDK is the platform. Both are defined via specifications, not via implementations. The former naturally cannot be GPLed. A more precise statement would be that, of available fully conformant JDK implementations, none are GPLed. I'm not sure that is even true though, as IIRC Kaffe+Classpath do fully implement some JDK version (1.1, I think... or is it 1.2 already?). Another issue is that Sun's reference implementation of JDK 1.5 is not GPLed. Note that these are two different points, and saying that "Java is not GPL" does not properly convey either of those. -- int19h 07:14, 20 November 2006 (UTC)
There's only one "Java", because Sun owns the trademark, and Sun isn't licensing the name for anything but its own platform. The "Java" platform source code (as defined by the only party that can define it) is not free software, because the runtime environment is not free software. There are some partially-Java-compatible free software projects, but they are not Java, so they are not pertinent to the status of Java. Let me know when I can copy/paste the (not "a") Java(tm) class library into a free software project. - 70.69.42.228
I might be wrong here, but IIRC Sun does certify third-party Java implementations, thus allowing their developers to use the "Java" trademark. There was IBM's certified Java implementation for sure, and I think also BEA's. Technically there's nothing precluding a fully compliant FOSS implementation of Java to get such certification either, if there were one (and somebody would be willing to pay for the certification process). Therefore, there is no such thing as "the" Java VM, Java compiler, and Java class libraries - there is a well-defined set of interfaces for all three, and there are several implementations certified to conform to those interfaces - all of which can be formally and legally called "Java" - though Sun's implementation is by far the most popular. -- int19h 07:10, 21 November 2006 (UTC)
True. What I mean is that Sun only licenses the name "Java" as they see fit, and so far it's only been for non-free software that clones their environment, and that software may or may not have been based on Sun source code. Either way, the fact remains that there is no free software product that has been licensed as "Java", or that is compatible with what Sun is currently calling "Java". I mean, show me how I can have a free-software-only machine that can run any Java binary that Sun's current non-free platform can run. - 70.69.42.228
POV does not mean a fact is uncomfortable for you. Facts can't be POV at all. POV means subjective commentary, or falsehoods.
At present, the following are FACTS (objective/tangible matters) and are not subject to POV, though you're welcome to phrase them "gently", so long as the objective data is not censored.
* Sun is currently not distributing a free software JRE. It has only announced that it may/will in the future.
* Only Sun has a definition of its trademark "Java". Only Sun can legally define "Java" or authorize it to be defined. "Java" has not been formalized or made into a world-accessible standard like Ecma, the ISO, and the ANSI would provide.
While this is true, it is not an issue with regards to standardization. All Java-related standards are still available and can be implemented by anyone, and the result will be a conformant Java implementation. Sure, you won't be able to call it "Java" for trademark reasons, but who cares? -- int19h 07:14, 20 November 2006 (UTC)
Anyone who wants a portable application would care. Leotohill 16:40, 20 November 2006 (UTC)
I'm not sure what trademark issues have with portability. If you write your application in Java, you know that it will run on any implementation of Java - even if that implementation cannot officially call itself a "Java implementation" for trademark reasons. -- int19h 07:10, 21 November 2006 (UTC)
Trademarks don't really matter, but standardization does. Proprietary MSDN and Sun specifications are a far cry from the guarantee of consistency and neutrality that an Ecma or ISO standard offer. - 70.69.42.228
* The JCP gives Sun a formal right to veto potential contributions.
To the standard defined by Sun as Java, yes. So is ISO not required to accept your contributions to ISO C++ standard. That's why it's called a standard - because there exists some final authority in deciding what is included, and what isn't. -- int19h 07:14, 20 November 2006 (UTC)
The difference is that ISO and other such organizations have an open process defined by their bylaws. The bylaws have been carefully developed to foster trust in the organization. While the JCP also (I assume) has bylaws and fosters trust, it cannot be compared to ISO-like organizations because the JCP does not have the final word. The comparison must be made between the Sun Microsystems and standards bodies. In this comparison, Sun is a closed process, while the standards orgs have an open process. Leotohill 16:40, 20 November 2006 (UTC)
That's specifically why it's not a standard: the fact that it's not governed by a neutral, unbiased, stable process. It's the opposite: a project that is arbitrarily administered by one commercial vendor, like IE or Flash. Proprietary projects specifically fly in the face of standardization precisely because they're dominated by one corporate entity. - 70.69.42.228
* Sun owns the copyrights for most of Java, and a release under the GPL does NOT change that.
If you mean the reference implementation, sure. So does Microsoft own copyrights on Rotor (and, of course, .NET, which is effectively the reference implementation for ECMA C# and CLR standards). So? -- int19h 07:14, 20 November 2006 (UTC)
It's pertinent to the subject of licensing because it means that Sun still controls the licensing of its Java software. It also means that the GPL won't necessarily be enforced. - 70.69.42.228
No, it doesn't. The moment they release it under GPL, they cannot revoke it back. They can restrict the licensing of the next version of Java, of course - which is why it doesn't make much sense to talk of "opensourcing Java"; what happens is opensourcing of a particular implementation of a particular version of Java. -- int19h 07:10, 21 November 2006 (UTC)
A release under the GPL only means that you can not sue anyone for taking that particular source code, editing it, distributing it, or running it. Sun will still retain all other copy rights, though. Sun will be able to: distribute binary-only modified versions that lock the GPL'd version out of compatibility, license Java to third parties for non-free purposes, license Java to the public under other licenses, opt not to enforce the GPL for violators, etc.. - 70.69.42.228
* A release under the GPL does not make Java any more or less standardized.
Also, on the GPL'ing of the Java VM and compiler, I'm replacing a ref of http://www.sun.com/2006-1113/feature/index.jsp with a [citation needed] because the link doesn't provide any information on when/where the GPL'd source code is available, or any proof that it even is available.
I'm removing the [citation needed], since the ref does provide all required information. On the right, under "Get the source code", click "OpenJDK", then go to downloads. -- int19h 07:14, 20 November 2006 (UTC)
I see, my mistake. - 70.69.42.228
Also, this sentence doesn't make sense: "The .NET runtime is Closed-source, although Microsoft is currently distributing a shared source version of its .NET runtime environment for non-profit use." Is it closed source or not? The answer is that much of it is not, that's what "shared source" means.
Agreed, "shared source", while disliked by many F/OSS advocates, is not exactly closed-source either. -- int19h 07:14, 20 November 2006 (UTC)
All contributions to Java are subject to veto by Sun : I think this is not true, at least in the extent implied by the sentence, see here the last JCP which does not mention any veto power at all : [7], and also this Jonathan Schwartz interview : [8] : While Sun has representation in the Java Community Process and works on many of the expert groups, it has no blanket veto power. We can veto a change to the language or the creation of a new edition - that's all. And we've never even done that.;
Ultimately, Sun owns the copyrights and trademarks anyway, and the JCP is really just a theoretical rule set, not a legal obligation. Sun can reject anything they want, they have an implied legal "veto", but even within the JCP rules, Sun does have veto power over anything that could actually make its way into Sun's material. I suppose that's why the veto is there, so that Sun never has to assert their proprietary rights and ignore the JCP. Either way, the fact that Sun can legally and logistically control what becomes "Java" is pertinent to this comparison, as Ecma and the ISO control a lot of C# and the related standards, and Microsoft has no direct control over that process. - 70.69.42.228
Another sentence I think is not accurate : C#, the CLI executable environment, and much of the corresponding class library have been standardized and can be freely implemented without a license : I would remove the class library from the sentence, which is not defined in the ISO / ECMA standard at all;
I was under the impression that some of the classes are included in the standards, but that Windows Forms, the Windows Foundations, and such, are non-standard extensions. I haven't thoroughly researched this, can someone post a link that sheds some light on exactly what has been standardized? - 70.69.42.228
Releasing Java under the GPL will not mean giving up copyright or trademark proprietorship : I would also remove this sentence, because it is true of every GPL application, it is not specific to Java;
It doesn't need to be specific to Java, it needs to be a fact that applies to Java and is pertinent to this comparison, which it does and is. It goes to explain the licensing status of Java, which is that Sun will have waived some of its rights to the source code as defined in the GPL (if/when they actually do it), but they will still retain the trademark (so no free use of the name "Java"), they will still be able to license the source code under other licenses to the public or specific parties, they will be able to release non-free Java builds that are different from the GPL' versions, or license others to do so, or simply refuse to sue GPL violators. A key point here is that the GPL will not apply to Sun and friends in any way, shape, or form. You and I won't be able to publish non-free modified Java builds without risking a lawsuit, but Sun and anyone they like will be able to, which is a major limitation of this move. - 70.69.42.228
Most of Sun Java is not currently available under a free software license : I think using most is POV, plus they have already open-sourced a very valuable part of the Java platform, the Hotspot VM. Hervegirod 20:39, 20 November 2006 (UTC)
Changed to The standard Sun Java runtime environment is not currently available under a free software license. Though, really, the class library is most of the Java platform, in terms of lines of code and functionality. - 70.69.42.228

[edit] JCP

Sorry to add a new subject, but Standardization became way too long. I still think (and its more than only thinking) that the sentence All contributions to Java are subject to veto by Sun and approval by the Java Community Process (JCP) is not neutral, and more importantly it is not true. You can write that ultimately, Sun's control the very existence of the JCP, but not this, there is no particular veto power by Sun on all JCP contributions (see the JCP on Sun's JCP site, the terme veto is even not mentioned). Hervegirod 22:03, 21 November 2006 (UTC)

Quoting dictionary.com (the American heritage dictionary), veto: An authoritative prohibition or rejection of a proposed or intended act. or from oxford compact english dictionary: 1 a constitutional right to reject a decision or proposal made by a law-making body. 2 any prohibition. - 70.69.42.228
The rules of the JCP are moot, though unless I'm misinformed, they grant Sun unlimited power to reject anything, anyway. Sun has a legal right as the proprietor of Java to reject any change to Java. Whether or not the JCP uses the word veto isn't the criterion here; it's whether or not sun can effect a veto, which it absolutely can, in numerous ways (JCP rules, copyright, trademark, forking Java if necessary, and so on). In comparison, Microsoft can veto any change to .NET and MSDN in exactly the same way, but not to the Ecma and ISO standards. - 70.69.42.228
Re-reading the text of the last version of the JCP, these rules do not grant power to Sun to reject changes (It is true that we often see articles about Sun's veto power over the JCP, but I think this is partly misinformation coming from IBM, who maybe wanted to rule Java in lieu of Sun...). And even the JCP process is governed by the JCP. Trademark, forking, etc... is off topic (even if these are possible moves by Sun, which I don't object), as the sentence speaks about the JCP itself. So I still think that the sentence is inexact. Hervegirod 00:12, 22 November 2006 (UTC)
Absolutely nothing can go into Sun's Java source code or anything licensed under the trademark "Java" against Sun's wishes, that's a legal fact, and it's pertinent here. The amount of power that Sun wields within the JCP is not withstanding because any results of the JCP are subject to Sun's copy and trademark rights, by law, not by JCP rules. The JCP is irrelevant to the fact that Sun has absolute legal veto power over changes to their source code, literature, web site, and anything trademarked as Java. (unsigned entry by 70.69.42.228 )
I finally had to go read the JSP document http://www.jcp.org/en/procedures/jcp2 for myself. It took a few minutes to find the key point, but I did. It is
"EC ballots to approve UJSRs for new Platform Edition Specifications or JSRs that propose changes to the Java language, are approved if (a) at least a two-thirds majority of the votes cast are "yes" votes, (b) a minimum of 5 "yes" votes are cast, and (c) Sun casts one of the "yes" votes. Ballots are otherwise rejected."
Sounds like veto power to me. When the US President refuses to sign a bill passed by Congress, it is called a "pocket veto". This seems strongly analogous. . Leotohill 02:23, 22 November 2006 (UTC)
it is only for EC ballots to approve UJSRs for new Platform Edition Specifications or JSRs that propose changes to the Java language. For all other changes, the rule is Except where noted otherwise in this document, EC ballots are approved if (a) a majority of the votes cast are "yes" votes, and (b) a minimum of 5 "yes" votes are cast. Ballots are otherwise rejected., on which Sun's vote count for one as for any other changes. I don't ask to delete the sentence, but as it is, it is no exact : All contributions to Java are subject to veto by Sun would be changed to something like Contributions to Java that propose a new version of the JRE /JDK, or a change in the Java language specification must be approved by Sun. That sentence would be exact. Changes that do not imply a change in the language (such as changes in the class library) do not require Sun's approval. Hervegirod 23:09, 22 November 2006 (UTC)
Your assertion is false. The statement Changes that do not imply a change in the language (such as changes in the class library) do not require Sun's approval is simply not accurate because Sun has a legal right to reject any and all results of the JCP. The rules of the JCP are NOT withstanding to Sun's blanket legal veto power over their Java trademark, source code, and reference material. If you want to prove that Sun doesn't have veto power, you have to prove that Sun literally and legally can not prevent a change to Java, which can not be proven, because Sun can veto any change to Java, whether it's an approved change by the JCP, a request by a corporate partner, a request by a member of the public, or whatever. Sun could bow out of the JCP and be removed from any/all JCP rules, losing its vote entirely, and Sun could still veto anything the JCP produces because Sun is the legal proprietor of the actual material. Legally, the JCP is an advisory process only, it does not supersede the veto power that Sun has over any would-be contribution to Java from any and all sources. - 70.69.42.228
I won't argue anymore, but you are not neutral here, why don't you accept the truth on that matter ? Hervegirod 19:45, 23 November 2006 (UTC)
Neutrality means sticking to the facts, and it's a fact, under US law and various international treaties, that no party, including the JCP, can force Sun to do anything against its will with its intellectual property. It is lawful under US federal law for Sun to ignore or even shut down the JCP, whether the other participants like it or not. Therefore, the JCP is not an exception to the fact that Sun controls Java. Sun plays nice with the community by voluntarily working with the JCP, and good for them, but it is voluntary, it is not a legal obligation. - 70.69.42.228

[edit] License

Sorry to add to the discussion once more. But I now think that saying The Mono project avoids infringing on any patent or copyrights, and so the entire project can be safely distributed and used under the GPL is inexact. It is true that the project (alongside with SUSE) is protected from Microsoft patents threat, but it is a result from the Microsoft- Novell deal , and 1) Microsoft CEO is saying that Linux infringes a lot of Microsoft patent, and 3) Novell said that they infringed no patent (see this discussion here). Hervegirod 23:24, 22 November 2006 (UTC)

When I added the quoted sentence, I changed the ref to point to an entry in the Mono FAQ Could patents be used to completely disable Mono? that details the steps that the Mono project takes to avoid infringing IP rights, and that provides some other information on Mono and IP. - 70.69.42.228
there are some Microsoft patents on some parts of .NET that are reimplemented by Mono, mainly parts of the BCL (not the C# language, of course, as it is under the ISO / ECMA standard). Hervegirod 06:47, 23 November 2006 (UTC)
Again, the Mono FAQ addresses this issue, please see the ref that I mentioned: http://www.mono-project.com/FAQ:_Licensing#Patents - 70.69.42.228
The FAQ says : For people who need full compatibility with the Windows platform, Mono's strategy for dealing with any potential issues that might arise with ASP.NET, ADO.NET or Windows.Forms is: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless. Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono.. So I still think that the sentence should be rewritten. They never say in the FAQ that they are sure that they don't infringe any patent, but basically that they : 1) are sure not to infringe any patent in the part covered by ECMA/ISO (C# language); 2) try not to infringe patents for the BCL (as for Windows.Form) by various strategies (see here, what about people using Mono, but not on Suse ?, or here, or here). Why don't you want to change the sentence by something like The Mono project does not infringe on any patent or copyrights for the part covered by the ECMA/ISO standard, and a deal between Microsoft and Novell further insures that Mono applications could be safely distributed and used under the GPL, even when using the whole .NET API. This alternative wording would be exact and neutral. The problem in the actual sentence is in the meaning of the term avoid, it carries the idea that avoiding has been (surely) successfully achieved, which is not what the FAQ says (and even if the FAQ said it, would not be sure). try to avoid would be better, but I think is also sort of POV. Hervegirod 19:43, 23 November 2006 (UTC)
The patent status of Mono is clear, and the Mono FAQ's answer is complete. Patents covering the standardized parts of .NET may be freely used by free software, so they're not an issue. For proprietary components, the Mono project's policy is to break compatibility with .NET if the only alternative is patent infringement, so patents covering proprietary components should never apply to Mono, and if they do, Mono's policy would be to immediately drop the applicable code. Additionally, there is the Novell deal, which would shield Mono from Microsoft patent suits even if Mono did infringe a Microsoft patent in the process of implementing the non-standard libraries, so Mono doesn't really need to avoid any Microsoft patents, anyway, but it still does. Basically, it is the Mono project's official policy that the project absolutely will not violate patent rights, and the FAQ gives a conclusive answer to that effect. If the FAQ is accurate, Mono does not and will not infringe on any patents. - 70.69.42.228
There are two important points that I believe have been overlooked.
1) The MS-Novell agreement does NOT mean that MS has agreed not to sue over patent rights in SUSE and Mono. It only asserts that "Microsoft will not assert its patents against individual noncommercial open source developers" and with, respect to SUSE, "individual contributors to OpenSUSE.org whose code is included in the SUSE Linux Enterprise platform, including SUSE Linux Enterprise Server and SUSE Linux Enterprise Desktop."
This leaves open the door for MS to sue distributors (i.e., non-individuals) such as Novell and Red Hat.
(see http://www.novell.com/news/press/item.jsp?id=1196 )
(I do believe that the agreement is a good sign of MS's willingness to allow non-Windows versions of .NET, but it is not a green light.)
2) Mono's intentions to avoid patent issues is all well and fine, but doesn't mean that there won't be significant issues. It's not as if it is always easy to determine what is patented, and what is not. Then, should MS assert a patent violation in Mono, it could sue for damages. Re-writing the offending code to correct the alleged violation might make it possible to continue distribution of the product, but damage suits against distributors could be stifling.
Regarding the sentence in this article, I believe that it should be rephrased to something like "The Mono project claims to avoid patent violations."
Leotohill 18:49, 24 November 2006 (UTC)
Good points. I've reworded it to The Mono project avoids infringing on any patent or copyrights, and to the extent that they are successful, the project can be safely distributed and used under the GPL. - 70.69.42.228

[edit] Variadic Functions not present in Java SE 5

The following text, specifically the highlighted section, is inaccurate. Java does not support variadic functions in any release.

"With the Java 5.0 release, this trend may have been broken, as it introduced several new major language features: foreach statement, autoboxing, methods with variable number of parameters (variadic functions), enumerated types, generic types, and annotations. It should be noted that all of those, except generic types, were already present in C# by that time, some under different names.[13]"

Specifically, this text appears under Popularity and evolution, in the Usage section.

Does anyone have a source for this (namely, because if I'm wrong, I'd love to start using this syntax in my Java code)? Rkausch 17:38, 24 November 2006 (UTC)

As far as I can tell, Java doesn't support variadic functions, so I put a [citation needed] on the statement. Hopefully someone can shed some light on this issue. - 70.69.42.228
Java supports what it calls varargs (see Java syntax#Varargs) - Chip Zero 19:44, 24 November 2006 (UTC)

[edit] Multicasting?

Is this meaning of multicast official or just made up? Anyway the link points to a completely different meaning of multicast, so you'd have to create a new multicasting (programming) page, or something like that. Seen also on SR (programming language). --lynX 07:52, 27 November 2006 (UTC)

That's what Microsoft calls delegates which invoke several methods when invoked once. And yes, it's an "official" name - the base class for all such delegates is System.MulticastDelegate. -- int19h 11:04, 27 November 2006 (UTC)

[edit] Portability of Rotor

The article as it is claims that Rotor can be compiled on WinXP, FreeBSD, and MacOS X. While it was certainly true for the first version, it doesn't seem to hold for v2.0 - at least the download page explicitly states that "the current release builds and runs on Windows XP only". Strangely enough, it is still distributed as a .tgz file, and there are Unix shell and Perl scripts inside which seem to be related to a Unix build, so I'm not sure what's the current status of Rotor on FreeBSD/MacOS. Can anyone clarify? If not, I think it's safest to go with what is officially claimed and correct the article to say that the latest version of Rotor is Windows-only. -- int19h 18:23, 3 December 2006 (UTC)

I edited the article in that way (I even added a link about someone who couldn't port Rotor 2.0 on Free BSD), but feel free to revert my edits if there is evidence that Rotor is still working on non-Windows platforms. At least, it is not supported anymore on Free BSD and Mac OS X. Hervegirod 19:10, 3 December 2006 (UTC)
I've updated the mention, hopefully clarifying the subject. 70.69.42.228 19:33, 3 December 2006 (UTC)

[edit] API Stability

A new section API stability was just added. While .NET has a comprehensive list of all breaking changes, both parties make use of breaking changes as well as API deprecation with new versions. Java 1.4 introduced the assert keyword for example, that broke many testing API's (which had to change their method name to assertTrue). (C# on the other hand made sure that new keywords such as yield were not reserved.) Even Java 1.6 made breaking changes fixing a bug in the PriorityQueue class, and there are many more examples. And this is not necessarily a bad thing, and neither is documenting these breaking changes. I removed the section for now. - Chip Zero 11:41, 2 January 2007 (UTC)

Why deleting this part ? It is well known that the Sun / Microsoft approach for the two languages are very different on that matter. I have no problem at home to use old (sometime very old) Java apps with newer JREs. The two changes I remember that really broke apps (but just when trying to recompile, not at execution) was assert in 1.4 and enum in 1.5. I don't think it is the same with .NET. Look here for example : .NET runtime breaking changes and .NET designtime breaking changes. But this section was not intended as a critic on .NET only, the two ways have their pro and cons (and I honestly thought I presented the two points of views, such as not to present Java way as good and .NET way as bad). Hervegirod 16:29, 2 January 2007 (UTC)
All .NET runtime updates include binaries for every previous major release, and the .NET runtime executes .NET programs on the nearest available version (normally the identical version) of the runtime that the program was compiled against. For example, a program compiled for the 1.0 .NET runtime will execute on the 1.0 .NET runtime on a machine that has version 3.0. Microsoft's compiler and build tools also allow you to select the language version to use in compilation, so if the language were updated in a way that would break your old code, you could compile that specific source--or your entire project--using the old syntax. Also, Sun has documented many backward-compatibility issues between Java runtimes,[9] and in Java's case, they actually are liable to disable older binaries on newer runtimes.64.59.144.22 19:30, 2 January 2007 (UTC)
.NET too has its share of methods marked Obsolete (another term for deprecated), and I believe there are no methods or classes that were removed in later versions. The same is obviously true for Java. Those breaking changes that are documented for .NET are of another nature: not the API interfaces changed, but only their internal workings. Same goes for the Java PriorityQueue example I mentioned: if you wrote an application that used it in Java 1.5, you may well find that your application no longer works in 1.6 since the implementation changed. And your application definitely will still compile, and probably won't even throw an exception, but it may horribly fail nonetheless. Most of the "breaking changes" listed for .NET are such bug fixes, that will help future (and existing) applications but may break older ones that depend on the bugs. Java has a long history of such small (logic) bug fixes, that WILL break certain older applications. Apparently they are documented somewhat better than I thought (at least for the older releases - is there such a list for Java 6?). So while we could say something about running different framework versions side-by-side (good point, anonymous), I don't think there are any other real differences between the two to make a section about. Anyway, other than that, keep up the good work Hervé. - Chip Zero 21:03, 2 January 2007 (UTC)
Providing access to the exact libraries that a program was compiled against is a major part of Microsoft's .NET compatibility strategy, and it does ensure that everything "just works" in a way that Java doesn't. You don't need to manually install multiple runtimes, it's a built-in feature, where the 2.0 runtime contains the 1.0 runtime, the 3.0 runtime contains the 1.0 and 2.0 runtimes, and so on, and it neutralizes backward compatibility problems at runtime level. You can use the current version of visual studio to develop ISO C# code that will use the 1.0 runtime on any machine with any updated version of the runtime, or if you developed a program when the ISO syntax and 1.0 runtime were current, your program will use the 1.0 libraries and "just work" on more recent runtimes. 64.59.144.22 21:34, 2 January 2007 (UTC)
I was under the impression that there where more inconsistencies between .NET versions than Java. It seems I was wrong !! Hervegirod 02:00, 4 January 2007 (UTC)
I don't know about more, but they do exist. If you copy/paste code that worked on the 1.0 framework into a 3.0 framework application, it could create a problem, though that would be unlikely. However, you're simply not forced to use the updated libraries, so there's no problem related to binaries or source randomly breaking with runtime updates. You can really only run into a problem when you want to use code that was thoroughly tested on an older version of the framework in an application or library that will link against and run on a newer version of the framework. For instance, if you have a large physics engine that was well tested on the 2.0 runtime, and you want to make it run on the 3.0 runtime so that you can use some windows foundation apis, some new bugs could pop up in the old code. —The preceding unsigned comment was added by 70.69.42.228 (talk) 19:15, 4 January 2007 (UTC).

[edit] API compatibility for Mono and GNU Classpath

I changed the content of the Desktop applications paragraph, as it seems it was not clear : Mono claim to have support for the core API for the .NET Framework 2.0, but not a guaranteed compatibility : Notice that Mono 1.1.x already contains many of the 2.0 features and class libraries, there are just no guarantees that they are complete, you will have to compile and test your application with Mono. Plus Mono is 99% compatible with Forms 1.1 (a preview of Forms 2.0 is planned for Mono 2.0). As Microsoft have already shipped C# 3.0, I found fair to reference, for Java, not the compatibility with Java 1.5, but 1.4. I think that saying that Gnu support was still incomplete, and Mono support was complete, was not accurate. Hervegirod 19:04, 14 January 2007 (UTC)

Whether or not you find it "fair" to point out that GNU classpath is not compatible with Java 1.5 is POV and irrelevant here. Please refrain from removing provable, referenced facts. 70.69.42.228 22:13, 15 January 2007 (UTC)
You re-added the sentence While Sun aims to provide the same or similar capability for Java, Windows does not currently ship with a Java runtime environment, Sun's Java runtime environment can not be included with free software operating systems..., but it is already included in the same paragraph : operating systems are currently unable to include any Sun Java Runtime Environment because Sun has not released its Java class library under a license that is compatible with the GPL.. We have no need to say the same thing twice here. For the rest of your modifications, I am happy with it, apart from While Mono has complete support for the standardized portions of Microsoft .NET 2.0, I would change complete by something else, because the Mono project itself does not claim to have now a complete support for 2.0 (see Mono Roadmap - Mono 2.0 will mark the time when the class libraries have complete support for the new features in the 2.0 edition of the framework. - Notice that Mono 1.1.x already contains many of the 2.0 features and class libraries, there are just no guarantees that they are complete, you will have to compile and test your application with Mono). My changes were not censorship, they were driven by the need for better accuracy (of course, the wording could be improved !!) Hervegirod 23:21, 15 January 2007 (UTC)
The only repeat there is Sun's Java runtime environment can not be included with free software operating systems, which is a mention of the previously discussed fact in order to put it in the current context of Java's lack of default universal availability. I've added (see above) to the mention. 70.69.42.228 01:55, 16 January 2007 (UTC)
Regarding the complete comment, the claim is that the standardized portions of .NET are completely supported, which is true and provable. This claim has no analog with Java because Java hasn't been standardized whatsoever. I've made the claim more explicit by stating that it's the parts that Ecma and the ISO have standardized. 70.69.42.228 01:55, 16 January 2007 (UTC)
I am OK with this part now. Thanks ! Hervegirod 22:33, 16 January 2007 (UTC)

[edit] Split this article into two: "Java vs C#" and "JRE vs Mono"

I've just removed a lot of political/legal stuff about the supposed issues with pre-installing the JRE on free software OS's like Linux. Somehow all this ended up in a section on desktop software(!!) I've moved it into its own section... however it occurs to me that there's a lot of 'tangential' material scattered throughout this article which has little to do with the differences between the C# and Java languages (and associated standard libraries) and has more to do with platform rivalries, politics and religion (small R.) Perhaps it is time we purged this article of politics, and/or moved it into its own article about the (alleged) fierce competition between the Java and Microsoft platforms...? JavaKid 13:25, 30 March 2007 (UTC)

Retrieved from "http://en.wikipedia.org../../../c/o/m/Talk%7EComparison_of_C_Sharp_and_Java_bf54.html"