Talk:Comparison of C Sharp and Java/Archive 1

Archive 1

Archive 2

Archive 3

Marking article as "advert"

C# is my favorite language, but this article still reeks of bias. I suggest renaming this article to Criticism of Java. It definitely doesn't deserve to be called a "comparision". —Preceding unsigned comment added by Nathanaeljones (talk • contribs) 19:02, 3 December 2007 (UTC)

"advert" is much too strong. It might have some npov aspects, but I don't think it's blatant. Please be specific in your objections. Leotohill (talk) 22:08, 4 December 2007 (UTC)

Seems to be less valid now 12:28, 30 June 2008 (UTC), but it still seems the article is a Smeagol/Gollum argument for the languages in question (not saying what's what - I'm neutral, since I'm for Algol 60). This might be remedied by stressing the different design philosophies, Java pressing for simplicity, language cleanness and security, while C# (seemingly) presses to prove all facilities that C++ provides, only yesterday. Said: Rursus ☻ 12:28, 30 June 2008 (UTC)

The design philosophies of the two languages really aren't as different as you may think, they just have a very different history and different roots. You believe Java presses for "simplicity and cleanness?" Then what about inner and anonymous classes (powerful, but ultimately complex and verbose)? Or take generics, using erasure, they are far from simple and secure as well. And don't get me started on the proposals for closures and expression/statement-level annotations... (Actually, closures are a Good Thing, but they essentially turn anonymous classes into a complex and verbose legacy feature.) And as for C# pushing to provide all C++ facilities, they actually disabled a number of features that exist in C++ and Java, such as fall-back through switch cases and returning a value from a finally block. Now don't take me wrong, I'm far from a fanboy of C#, and really like the Java Platform for its openness and portability, but just think the Java language could have been better. Mfb52 (talk) 16:17, 5 July 2008 (UTC)

The article currently claims it "documents the strong general similarities of the languages and then points out those instances where the languages differ", but I think a more accurate description would be that it lists several of the features of C# with occasional side commentary on Java. Take "object contexts" for example:

"C# supports the notion of contexts for objects. Instances of normal classes (termed agile objects) are created without a context; but certain classes, notably the ones which specialize ContextBoundObject, are managed by a context. The mechanism is used for aspect oriented framework features such as transactions, syncronization[sic] etc."

There is no mention of Java in the entire section. Does that mean that there are no contexts for objects in Java? Are there any comparable features in Java? If it is unique to C#, then that should be explicitly stated. The entire article seems to follow this format, which leaves the reader with no sense for either of the two languages. tmcdouga (talk) 15:16, 18 July 2008

the paragraph about ContextBoundObject should be removed, because it is not a language feature: it is a library feature. I'll remove it.

custom object contexts are no more library features than weak and soft references are. Context bound objects and weak/soft references are platform features with support through libraries. The languages have no special syntax for soft references, weak references or object contexts. By that notion, the entire section on "references" should go as well. If this is a comparison of the languages (the narrow definition) weak/soft references, object contexts etc. don't belong here. If you take the article as a comparison of the languages with their underlying platform (because the have become impossible to seperate) but ex. libraries, the references and object contexts belongs there as they are ways to control platform features such as GC and method dispatch. —Preceding unsigned comment added by 87.58.44.93 (talk) 22:27, 27 July 2008 (UTC)

I deleted the weak/soft references parts of the references section; as they a obviously as much library features as object contexts. 87.58.44.93 (talk) 09:25, 28 July 2008 (UTC)

I guess I opened up a sticky problem by deleting the ContextBoundObject. It's true, there's more of the article that should be removed if we want to keep it strictly limited to lanaguage features. I found the ContextBoundObject content particularly bothersome, as compared to the other content that strays from language-specific. I do think that there is a clear difference between it and features such as weak and soft references. ContextBoundObject does not map directly to a VM feature, while weak/soft references do. Most of the rest of this article that is not language-specific describes features of the VM (garbage collection, references, generics) instead of library functionality. Does that make it any more acceptable? Perhaps not.

Content that is removed from this article, for these reasons, should probably be inserted into Comparison of the Java and .NET platforms. I didn't find the ContextBoundObject information significant enough, myself, to be inclined to place it there.

Agree that it is a bit of a problem. I actually see three entities here: Platform (the VM/Intermediate language), programming language (C#/Java), and the base class library. ContextBoundObject definately maps to a VM feature, as it causes method invocations to be intercepted and proxy objects to be (transparently) created for "clients" outside the context. I agree that it is a rarely used feature (like soft references); but all of them still have VM backing; they are not just library functions even though they are part of the BCL. Perhaps there's a hint in the namespace/package conventions. The (.NET) System namespace and the (Java) java.lang package both contains features which maps to such platform specific features. Ruling out such features would also mean that JNI and P/Invoke could be considered not part of the language. I believe that features of said namespace/package should be allowed into this article. That would put back soft/weak references, contexts etc. 87.58.44.93 (talk) 21:00, 28 July 2008 (UTC)

Leotohill (talk) 13:28, 28 July 2008 (UTC)

I'd be fine with seeing "no such feature appears in java/c#" where appropriate. Go for it.

The existence of more listed features on one side than the other is not prima facie evidence of bias, nor is is necessarily evidence that one language is better than the other.

Leotohill (talk) 21:33, 21 July 2008 (UTC)

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.

This comment is in such poor English that is it difficult to understand.

What is a CLUF?

Whether CLUF or EULA restrictions are legally enforceable is largely moot if Microsoft's legal team decides to enforce them. If people don't read software licenses, then they have no-one to blame but themselves if they find themselves in court for violating those licenses.

If Microsoft decides to include license terms that state that everyone using their software must be named 'Bob', and you agree to those terms (whether implicitly or explicitly), then you are required to change your name. Hi, Bob!

Primitive Types

The article states that Java primitive types also exist in C# and are known as value types, According 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)

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.

Good point, the trouble is that there's not any fixed compsci terminology. Sometimes reference counting counts as garbage collection, sometimes it doesn't. This is an extremely frustrating fact of compsci. Said: Rursus ☻ 12:31, 30 June 2008 (UTC)

General discussion and enums

I removed "This allows one to combine enumeration values together using the bitwise OR operator if they are bit flags" and rewrote the sentence: "A special enumeration set object is needed to combine enumeration values together", since that is inaccurate. You can use bitwise OR "enum sets" in Java (use .ordinal()), but the EnumSet and EnumMap classes provide full type safety and readability improvements with minimal overhead costs. Developer38 (talk) 01:28, 1 June 2008 (UTC)

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)

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)

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)

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?

More language features do not necessarily make languages easier. Image if "goto" did not exist; would you argue it would be a useful feature to let the programmer jump to anywhere in the code, thereby breaking the structured programming model?

Also, your vocabulary example is a strawman. If my vocabulary was halved, then you are correct: expressing myself would be harder. But understanding me would be easier. For my money, understandable code is more valuable than featureful code. Language features should not be added because they make something easy; they should be added because they make something possible.

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

But that's the trade-off with any language design. The designers of Java decided that (for example) pointer arithmetic was just too abusable to include in the language. Some people can do it very well; some people create a complete mess. Likewise, delegates can be abused, so the Java designers decided to omit them.

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)

Performance is not a consideration for language design (though it is a consideration for language implementation). Any discussion about language features based on the supposed performance of those features is misleading.

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.

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)

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)

'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)

Something to keep in mind when using Google/Amazon/CodeProject searches for comparisons like this: Java has been around significantly longer than C#. That there have been more Java developers than there have been C# developers is a different question than whether or not there are.

To cite a counterexample, it would be hard to argue that the COBOL community is more vigorous than that for Microsoft Silverlight, yet the first term turns up 7.9 million results in Google, the latter only 2.3 million. —Preceding unsigned comment added by 12.158.176.10 (talk) 21:27, 14 March 2008 (UTC)

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)

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)

AfD result

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

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)

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)

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)

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)

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)

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

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)

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)

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)

reorganization

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

removed similarities / differences

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

removed bullets

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

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)

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)

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)

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 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 , 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

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

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

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 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)

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)

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)

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).

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)

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)

It would be a good idea, I agree with this Hervegirod 23:47, 15 April 2007 (UTC)

Yep, that'd be nice, this article has more than its fair share of politics, while it should focus mainly on the language differences. I agree we should do a spinoff article. How about something like (Comparison of) .NET and Java platform deployment? We can then continue to focus the present article on the language, and a bit about the libraries and the community. – Chip Zero 09:34, 16 April 2007 (UTC)

Yeah, I'm beginning to think that section 3 and 4 attract too much POV editing, and add very little to the article, which IMHO, should focus more on technical issues and less on fanboy issues. Tbjablin 09:43, 16 April 2007 (UTC)

I edited section 4 on 13th April to add some structure, provide greater breadth by talking more about the Mac, and adding issues about browser plugin deployment on Windows (problems which have been the source of much discussed in Java circles recently.) The edits were immediately reverted by 24.65.79.192 (I suspect because they didn't give due praise to Linux?) Now, while I'm not saying the text was perfect, its wholesale rejection is a little absurd. We ended up with a section which focuses excessively on Linux, briefly mentions Windows, and hardly touches on the Mac. It seems that section 4 is so politically charged that its now harder to write than a United Nations mandate.

I'm a Linux user myself (and a Java coder) but for a section which was originally supposed to be about DESKTOPs to relegate the two OSs which make up 99% of the market to bit parts is absurd (although I note someone has now retitled the section to make it more generic!) I think the whole of section 4 should be delete, ASAP! It has little to directly relate it to the subject of the article, and is causing far far *far* more heat than is necessary. I'm in half a mind to just cut it right now... JavaKid 15:41, 17 April 2007 (UTC)

I've been contributing to this article for the better part of a year and I made major contributions to a good portion of the sections. I understand and share your frustration, and I might be taking this a little personally, but I honestly feel that this article has fallen victim in the last couple days to the common wikipedia problem of a spin doctor with a bias on a given subject coming out of the blue and deciding the whole article needs massive revision, not with any kind of journalistic quality improvement or addition of facts in mind, but to change the spin of the article to suit some POV agenda. It just gives me a knot in my stomach to see facts removed and quality degraded because someone needs to see the article have a certain spin or tone. 24.65.79.192 16:58, 17 April 2007 (UTC)

For the record, I was the person who actually restructured this article all that time ago, after it got 'marked' for its poor quality. The overall structure, and fair bit of the content, is still mine. Not that that means I 'own' the article or anything (I claim no greater ownership than anyone else!) Because I'm mainly a Java programmer I tried to give as balanced an account as possible, recognising Java's (many) shortcomings while inviting the C# programmers to fill in the gaps in my C#/.Net knowledge. The aim was a balanced article, pragmatic about both languages and their associated platforms. And on the whole as it evolved it was okay -- sure, there was stuff that, as a Java programmer, I thought was a little unfair, but the important thing is not to get too partisan: keep in mind that both the good and the bad of your favourite platform need to be noted if the article is to serve any useful purpose.

When I re-visited this article a few weeks back I saw that a lot of it seemed to be very anti-Java. Java woes, its legal status, its deployment, etc etc etc, were covered in gory detail at multiple points in the text. While all these points are PERFECTLY VALID (and indeed highly worthy of note) the disproportionate amount of coverage coupled with the anal amount of detail was totally off the scale. Particularly as they were only vaguely on-topic for this article. Meanwhile suggestions that .Net or Mono was less than perfect seemed to meet with some resistance (or worse -- immediate revertion, as 'POV'!) Most of the 'Java-woes' stuff seemed to echo complaints rife within the Free Software community (like the exact, precise, specific, to-the-comma, wording of the Java license or why Classpath is not a suitable alternative to the Sun JRE) while a lot of the pro-.Net commentary seemed to relate to Mono (which Free Software advocates traditionally prefer to Java.)

Before I edited the text a few days ago it seemed to strongly hint that .Net/Mono was widely available as standard on the vast majority of desktop computers, while Java was only available on "some". I modified the article to note that Java is shipped out-of-the-box on the majority of Windows PCs thanks to OEMs (and provided a citation to back up this 'majority' claim) and is shipped as standard on all OSX Macs. I also added detail of the 'plugin download' mechanism used to get Java onto Windows PCs which do not otherwise have it -- **AND** pointed out its shortcomings and the many critisisms made against it. I also noted that the Mac does not ship as standard with Mono. All of these changes simple got reverted as POV. Why? Because someone didn't like the inference that Linux is not a mainstream desktop OS. Well I'm a Linux desktop user, but even I'm man enough to admit that Linux cannot currently be considered 'mainstream' in that particular field by anything other than the most twisted logic. But hey -- I'm also man enough to admit that in such a politically charged atmosphere it was probably unfortunate to use that turn of phrase. It was like a red rag to a bull, and I apologise for that. I should have been more careful

What the 'mainstream' argument reveals, however, is that going forward this article is going to become increasingly bogged down in politics. Every time someone so much as breaths on the text, the Mono and Java camps have to vet every comma and full stop, then argue the toss over detail which only 0.00001% of the audience (those with a political axe to grind) probably care about. As such, I'm suggesting the majority of section 3 and all of section 4 should be deleted. And I'm quite prepared to volunteer to do the work to port it over into its own article. The only issue remains: what should that article be called? "Java vs .Net"? "Java vs Mono"? "Critisisms of Java"? Or something else. PLEASE BEAR IN MIND: I strongly suspect the majority of the politics stems not from Windows (.Net) vs Java advocates, but Free Software (Mono) vs Java advocates. (Am I right in this assumption?) I suggest an article subject more in keeping with the free vs. proprietary software nature of the arguement(...?) JavaKid 19:56, 17 April 2007 (UTC)

Hi JavaKid. I see many of your points, and I'm sorry if I censored you or made you feel censored. I'd like to respond to your points as efficiently and simply as I can, but I don't want to gloss over anything, so I'll take them one at a time (though not in any particular order). On the subject of Linux not being mainstream, keep in mind that the global desktop market share of Linux is over 3%, and Mac OS is in the 2's. For the most part, it's being kind to Java to even talk about Linux and Mac as if they really have something to do with runtime availability. A more biased but maybe pragmatic point would be to assert that non-Windows desktops are a tiny portion of the market, backed by a variety of reliable references, and to put the entire emphasis on the fact that almost every Windows machine has .NET now, and Java only has partial penetration there. Also, I can tell you that from my personal experience, installing a Java plugin is a difficult process, and on at least one occasion I found that it didn't even work. Though, if you wanted to re-add a mention somewhere, I don't have any objection to that, and I wasn't really trying to censor the point. I'm also not sure that your data about OEMs providing Java is current. Microsoft has been pushing pretty hard to force OEMs to lock out Java, though I don't have any figures on how successful they've been. I simply don't feel confident about the data either way. 24.65.79.192 21:27, 17 April 2007 (UTC)

I'm not mad at the reverts -- just a little disappointed. This article is rapidly getting bogged down in pointless politically-driven detail, and all it takes is some rabid Java-fanboys to find it and we'll have all out warfare between the Mono and Java crowds. RE: Your figures for desktop market share, where do they come from? I've seen Mac users claim anything up to 5 or 6% market share. Do these figures come from an independent source, or were they taken from a Linux centric source? How were the figures gathered, and how reliable is that source? Is there such a thing as reliable figures on such matters? Besides, what does 'mainstream' mean anyway? Linux lacks Microsoft Office, Adobe Photoshop, and almost every other 'industry standard' brand. It is hard (although not impossible) to walk into a highstreet store and purchase a Linux PC. The Linux name has practically zero brand recognition outside of computer geeks. It all depends upon how you interpret the word 'mainstream'. Y'see -- it is *precisely* the fact that we end up dancing around the head of a pin trying to tie down terms like 'mainstream' so that they don't offend one side or the other which suggests (very strongly) to me that this article is doomed to a flood of nit picking and pedantic edits every time something changes. RE. .Net: there's an awful lot of old Windows machines still around devoid of .Net, such that MS had to extend the life of Win'98 some years back, and there's an awful lot of Windows PC's around with Java installed. As nobody has presented figures for one or t'other, I think we should avoid letting speculation and assumption enter into the article, no? (Ironically I seem to recall I actually made the same pro-.Net point you just made in an earlier edit, and someone has removed it!) RE. the Java plugin: ironically I touched on with some of the problems (and they are quite serious problems) in the passage you reverted. If you have reason to believe your problems with Java were commonplace (and better still you have a citation to prove it) then why not add them into the article rather than remove the plugin material entirely? RE: OEMs. I provided a citation which was two/three(?) years old. If you have a more recent cite then by all means update the passage -- but 'gut instinct' that the situation changed at some point in the last couple of years isn't enough to revert a change, especially one which cites a source. (I've been trying to get reliable data on .Net and Java installations, but there's little out there. I've also been trying to get some data on BD-J and HDi, but again, the only material out there is on partisan web forums which champion one DVD technology over another. Until someone provides reliable data I suggest we all stop making rash assumptions about how popular Java, .Net, Mono, C# etc etc are, based upon our own political likes, and show a bit of pragmatism?) JavaKid 23:02, 17 April 2007 (UTC)

Mac has a much larger desktop market share in the US than it does worldwide, that may be the reason for the confusion. Linux desktop and server machines are available from IBM, Dell, Acer, and others. I think you may underestimate how recognized and used Linux is now. I actually saw a funny though not necessarily journalistic spoof of an Apple ad about this recently on youtube: http://www.youtube.com/watch?v=rtp5gNhBZgo . You can also run microsoft office, adobe photoshop, and actually a majority of windows software under Linux. Or if you count xen and vmware, almost all of it. Either way, my main objection to implying that Mac but not Linux is mainstream wasn't so much that I felt it was inaccurate but that I felt it wasn't a claim that was made in the spirit of quality or information. I felt that your edits were politically motivated moves to try to spin in favor of Java, rather than an effort to improve the actual quality and informational content of the article. I also agree that it's hard to prove market share, and that it's probably better not to make any sweeping claims or to try to prove who has what share, at least in the scope of this article. I do agree that the mention of the fact that Java is available as a plugin may be a legitimate informational edit, even if a pro-Java bias is the obvious motive for wanting to add it, rather than concern for the quality of the article being a motivating factor. Facts are facts, though, and that fact is pertinent. If you had added only a mention of Java plugins, I wouldn't have objected. I also agree that 'gut instinct' isn't enough to revert a change, and your point that some OEMs provide Java is still there, precisely because I can't disprove the article from 2003, it is (or at least was) a basically credible source, and I wouldn't want to get into justifying removing it unless I have some hard data to the effect that things have changed. On BD-J and HDi, I personally don't care much. Though just on a side note, if HDi includes anything like the WPF/E web plugin then it actually has a pretty lush .NET environment, though I have no idea whether it does. Anyway, about some rabid Java-fanboy finding the article and freaking out, that seems to be exactly what has happened in the last couple days, but personally I don't like to be intimidated, and I can't stand silencing facts because some militant little group wants everyone to look the other way. I mean, if there are quality or verifiability or readability or journalistic concerns about some of the points that may seem critical of Java, then they should be addressed, but dropping anything that Java fans don't like because they might throw a hissy fit is ridiculous and about as POV as editing can get. 24.65.79.192 23:33, 17 April 2007 (UTC)

Your loyal defending of of the Linux desktop is admirable -- but you have still failed to tell us where your claim that Linux is more popular than Mac as a desktop stems from. Either way this is a mute point, as I'm already in agreement that labeling platforms as 'mainstream' is too politically charged -- even when it is only a brief throw-away reference in 'lead in' text to a paragraph. (Can I add, I think everyone should just chill out, stop being so pedantic, and show more pragmatism?)

RE OEM's: It is not sufficient to suggest that 'some' Windows PCs come with a JRE, when the evidence (citations) suggest the *majority* do, while at the same time resisting any changes which note the desktop platforms which do not have .Net/Mono pre-installed. Such downplaying of one platform, and hyping of another is biased. The original text (the one I edited) dealt with how universal the .Net framework and the JRE are without additional download. A legitimate topic. But the text was worded in such a way that it suggested Java scored badly on universality, while suggesting .Net was nearly ubiquitous. For Java, attempts to change 'some' to 'most' or 'the majority' were reverted, even when cites were provided. Attempts to point out that Mono is not pre-installed on all Unix flavours, and is not pre-installed at all on OS X (a fairly noteworthy OS in the marketplace) were removed entirely. The text also contained copious amounts of pedantic detail about all the legal nitty-gritty regarding the JRE, while no mention of any legal woes regarding Mono were mentioned (and attempts to add them, I noticed, were challenged.) The topic of universality is important, given both the CLR and JVM tout write-once-run-anywhere as a philosophy, Therefore it is vital that the failings of both platforms be appropriately dealt with.

The appropriate text would note that both platforms are very well supported 'out-of-the-box', but both have gaps. In the absence of any figures, I would suggest it is folly to imply that one platform is more universal than the other. If you want to re-write the section to note that both .Net and the JRE are extremely well supported out-of-the-box across desktops (with notable gaps for both) and neither has been shown to have a significant lead over the other, then that would be nice. If not, will you allow someone else to make the changes without automatically reverting? If not, will you provide some concrete evidence which supports your insistence that .Net is well supported, while Java is not? (You claim the Java cite is out of date -- can you back that up?) JavaKid 09:57, 18 April 2007 (UTC)

The appropriate text would state the facts and allow the reader to draw conclusions. The reference about OEMs, even if taken as current, doesn't list a majority or state that it's a majority, it lists some. Why aren't you upset that for C# it says "a number" for Linux distributions that include Mono? Fedora, Ubuntu, Suse, Debian, and others, this is definitely at least as strong a "majority" and "major" Linux distributions, but wouldn't you object to trying to spin it that way? Also, the text doesn't assert that a majority of OS vendors, or machines, or market share, includes .NET or Mono. It asserts who includes .NET or Mono, the facts, and allows the reader to decide. If you want to get into the nitty gritty instead of saying "many" about the available operating systems and processor architectures then be my guest, but you'll find that the end result is just an embarassingly long and pedantic list that if anything makes "many" look vague and unsupportive in comparison, and worse yet badly degrades the quality of that section of the article. Also, there's no mention of the fact that Mono can be downloaded and installed in operating systems that don't include it. Why not? Because it isn't pertinent, and isn't the same thing as actual inclusion in the operating system. Though, again, if you'd like to get into the nitty gritty of documenting every like fact that you feel suits Java, we can have a detailed section on just how many addon repos hava ready-to-go Mono packages that can be installed with a single command, and how .NET rotor can be compiled for non-Windows platforms including Mac OS X, and so-on and so-forth. Also, you may not like the facts about Java's not-so-user-friendly and far-from-free-software licenses, but that doesn't mean they need to be lobotomized to the point of being incomprehensible and/or moved to the back shelf or an article titled "facts that Javakid didn't like." 24.65.79.192 16:42, 18 April 2007 (UTC)

"Tuesday's announcement means that more than half of the PC desktops and notebooks sold will now include the latest version of J2SE, according to Green." More than half qualifies as 'a majority'. Even if you wanted to be mean spirited, it still qualifies as 'most'. Both of these wording changes have been reverted. Both are less misleading than the 'some' which you seem to prefer. Again. if you feel this reference no longer reflects the current state of affairs then you need to provide something a little more concrete than a 'feeling'. This shouldn't be too hard to do, after all, if OEMs have been dropping Java from their machines it's bound to have caught the attention of numerous tech news sites (and Java sites.) The C#/Linux stuff should also read "majority" or "most" if the Linux distros on which Mono is pre-installed constitute more than half the desktop Linux install base (cite?). Why was I not bothered by that? Because I'm not a Mono expert, so I have no way of knowing if that was right or wrong -- but if you'd have changed it to read "most" or "majority" I would certainly not have challenged it. I think the art to successfully contributing to Wikipedia is to write about what you know, and trust others to do the same. You certainly should not edit or revert for political reasons.

It is not a case of having facts that I like, or you like, or anyone else likes. I have no problem with issues and problems relating to Java being aired -- indeed I demand that they should be (because not doing so would be misleading and biased.) However, one simple cannot have paragraph after paragraph after paragraph going into every single problem with Java in minute detail, and then use weak wording like "some" when "most" or "majority" is more truthful, unless you are prepared to allow the same level of minute criticism and weak wording of C# or Mono or Linux, etc. And so far this has not been the case. And before you ask: YES!!!! I would be JUST AS VOCAL of an anti-C# bias (although I'd be less qualified to correct mistakes.) Can I remind you that this article is a comparison of the languages of Java and C#, not a history of the Mono vs. JRE debate? While articles frequently stray a little into associated areas (often usefully so) I suggest if you wish to document Java's issues (of which there are more than a few) AT LENGTH, can you do so in an appropriate article? JavaKid 09:33, 19 April 2007 (UTC)

Personally, I'm also not a big free software advocate. I like and understand the idea of being able to compile your own operating system, but I'm really a business minded pragmatist, and I mainly use Windows, Visual Studio, DirectX, and other technologies that simply offer greater market penetration and productivity than Linux can even begin to rival. I do believe that free software is misunderstood, that there are many misconceptions, and I try to defend it. For example, Tbjablin's edits seem(ed) to have no concept of the fact that a good portion of Linux distributions and users actually reject proprietary software. Personally, I've been thoroughly immersed in these issues for a decade. I've exchanged emails with Richard Stallman on many occasions. I've written articles about some of the good and bad (in my view) things about free software and the associated ideology. I'm sensitive to the subject, but I'm not a categorical supporter in any way. I don't give out my source when I give out a binary, for example. So when I edit in defense of free software, it's not holy warring, it's honestly that I value the integrity of wikipedia and I believe in having every side accurately represented, combined with a pretty thorough understanding and sensitivity to the concerns of people who can't stand proprietary software. 24.65.79.192 21:27, 17 April 2007 (UTC)

I'm also not a staunch supporter of .NET or Visual Studio. I mean it's certainly not free software, in spite of rotor, and it's certianly not without its flaws. The main reason that I feel compelled to go into detail about Java's conflicts with free software is what I see as the hypocrisy. I feel it needs to be said that Java is proprietary, but it doesn't need to be said with .NET. I don't mean that in the sense that we should shelter poor .NET from unnecessary criticism, as it almost seems some people feel about Java, but rather, I don't feel that Microsoft and the .NET community are trying to create a public image that actually conflicts with the reality. We all know that if you use Linux, you're out in the cold for .NET in many ways, and Microsoft isn't trying to pretend otherwise. Sun, on the other hand, would have us believe otherwise about Java, in my opinion. However, if you want to more thoroughly document how and why .NET is not free software and has no complete alternative in Mono, DotGNU, or any other project, I certainly have no objection, except maybe the possible objection that the community climate doesn't warrant it, and it wouldn't really improve the article's quality, but I certainly won't try to censor you. 24.65.79.192 21:27, 17 April 2007 (UTC)

Also, as a long time Wikipedia user, I've seen a lot of people trying to soften, strategically rearrange, or simply censor uncomfortable facts. I don't like it. To me, good edits are based on two main goals: providing information, and improving logical structure and readability. If you're moving or removing a sentence or paragraph because you feel that it contains a fact that makes you uncomfortable, and you're simply back-shelfing it because you want the article to seem more forgiving to a given side of a subject, then in my opinion, that's a terrible reason to make an edit, it really contributes nothing to the article, and I'd rather you just blogged out your feelings. I admit that I really resent what I see as deceptiveness on Sun's part, and I take every opportunity to expose them with hard facts, but I wouldn't take kindly to a pro-.NET person hacking up the article, damaging logical structure to back-shelf anything critical of .NET, rephrasing uncomfortable facts to obfuscate their meaning, moving around entire sections to put everything .NET-friendly in front, and so on. I really believe that a good article unabashedly lays out all verifiable facts, no matter who would rather they weren't seen, and then just tries to lay them out according to what will be easiest to read and comprehend, rather than what will be less offensive to certain peoples sensibilities. For instance, "I have bananas, but no milk, so I can't make a banana milkshake, but I guess as an alternative I can bake banana bread" makes more sense for obvious reasons (IMHO) than "As an alternative I can bake banana bread given that I can't make a banana milkshake because I have bananas but not milk." That kind of driving quality factor is what matters to me, not trying to bury facts that some people would rather not see. 24.65.79.192 21:27, 17 April 2007 (UTC)

One other thing. I've seen your "contributions" since the first edit you made to this article, I was already contributing to it at that time. In my opinion, you really haven't contributed much in the way of knowledge or facts, and making major back-shelfing moves of entire sections in an article doesn't mean that you're responsible for the information actually being there. Also, is Tbjablin a sock puppet of yours? 24.65.79.192 21:37, 17 April 2007 (UTC)

Ah yes, but then you seem to only qualify 'knowledge' and 'information' as something *you* personally agree with. For example, you apparently do not count the fact that Mono is not shipped as standard on OS X as knowledge, because you discarded it. And in the same edit you reverted the stuff about the OEMs (and in doing so cast Java in a much worse light compared to Mono) despite a citation backing it up, because you "don't feel confident about the data" -- fine, not a problem, if you had something concrete other than just a 'feeling'. As for my 'contribution' to this article: I should point out that my edits stretch back to before I actually registered as "JavaKid", and many are under an IP address. From memory (so please be kind if I'm a little off...) the original "Language" section was compiled by myself from bullet pointed statements already present, "Popularity and evolution" was written pretty much from scratch by myself, likewise "Marketplace", "Desktop applications" (which has had shamefully little added since I wrote it, and is still far too Java-heavy), "Server applications" (which has been edited a lot by others), "Mobile applications" (again, still mostly my stuff), and finally "Leading edge technologies" (mostly me again.)

Now you may think that I've been a little hard on you in the last para... but I did find your "sock puppet" comment more than a tad disappointing. Could I suggest, with the greatest of respect, that such comments are not condusive to an amicable resolution of these issues? I only hope "Tbjablin" whoever he is (and no, he isn't a stooge of mine -- this isn't a childish schoolyard game where we gang up on people) doesn't feel the need to retaliate. JavaKid 23:02, 17 April 2007 (UTC)

No, it doesn't have to be something I personally agree with. It shouldn't be subject to anyone's personal agreement, and it shouldn't be subjective it all. That's why it's so important for Wikipedia content to be verifiable. The section that you're desperately trying to censor is currently pretty factual and verifiable, especially the C# part, and the Java parts that you call critical. If you read through the C# part, no point is made that isn't a direct, verifiable fact based on references. For instance, "Microsoft is promoting C# as its flagship language." This is a verifiable fact, this is their stance, no commentary on whether this is good or bad has been added onto the claim, no "(a major software vendor)" has been put in for bias's sake, no claim that this means most machines, rather it's just the bare verifiable fact as directly asserted in the reference. "in part by including the .NET runtime in all recent Windows environments" - again, verifiable, though admittedly not referenced, but I doubt anyone has any doubts about this fact anyway, and it's easily provable if they do. "by distributing the Visual C# Express development environment at no cost" - verifiable, referenced, no commentary added, no "(a major and powerful development environment)" or any other spinning added. "C# and the CLI are included and used in a number of Linux and BSD based operating systems by way of including the free software Mono Project." - again, verifiable, referenced, and sticking only to the provable fact and basic factual wording such as "a number" rather than many/most/major. I think there's no point in going on, but the point is that the C# section is a work of fact, not speculation, subjectivity, spin, or fiction. Also, I'll add another fact in response to your concerns right now. "Apple's Mac OS X does not include the Mono project." No objection here, it's a fact, it's pertinent, there's no reason to censor it in any way including trying to spin it like "Apple's Mac OS X has so far failed to include the Mono project, but the Mono project is readily available for that platform, and provides the same features there that it does anywhere." 24.65.79.192 16:30, 18 April 2007 (UTC)

I do agree that splitting the article makes sense. I wouldn't split off just the section Runtime inclusion in operating systems, though. I think that renaming the article to something like Comparison of C Sharp and Java syntax, and moving everything but section 1 to Comparison of CLI and Java runtimes might be a better idea. 24.65.79.192 16:58, 17 April 2007 (UTC)

Split this article into two: A SOLUTION

I've just searched, and noticed that there is already an article, Criticism of Java. If someone (preferably not me, given my username) created a parallel Criticism of .Net (covering both .Net and Mono) article, then most of the politics can be moved into those articles. I do not want to jettison discussion of the frameworks and runtimes from this article, because there is lots of crossover between the languages and their runtime (for example, annotations and generics, both of which have language and runtime implications.) I also feel it is not unreasonable for moderate discussion of APIs (particularly stuff like Collections) to be listed in an article about language. My proposal therefore is to move to the 'criticism' articles any commentary of the following nature (note: Where I say "any discussion" is means a complete, or near enough, purge. Where I say "in depth discussion" it means some basic outline commentary, perhaps just one sentence, will remain, but nothing too detailed.) :

• In depth discussion of the Java vs Microsoft anti trust case.
• Any discussion of the Java license and/or legal status (even reference to Open Source -- legal status is a separate issue to language features and development.)
• Any discussion of the Microsoft/Novell Mono deal, and who it might or might not cover.
• In depth discussion of the origins of C# (eg: politically motivated or not?)
• In depth discussion which says Java copied C#, or C# copied Java, or everyone copied C++ -- except where these claims are backed up by reliable citation quoting someone qualified to know the truth (ie. someone at Sun or Microsoft. or of equal status.)
• Any discussion involving the universality or otherwise of runtimes -- it generates too much heat and there's practically no reliable data.
• In depth discussion on the relative merits or otherwise of the standardisation or development process of APIs and langaguage (ANSI / JCP / etc etc etc.)
• In depth discussion of the relative merits of the Java / C# development communities.

Please let me know how people feel about this. Many people have expressed a desire to see this article be stripped of a lot of the heavy politics stuff -- is this the right way to do it? JavaKid 11:03, 18 April 2007 (UTC)

I stated my opinion above. You didn't really respond. My suggestion was renaming this article to "Comparison of C Sharp and Java syntax," and then moving all but section 1 to a new "Comparison of CLI and Java runtimes" article. Personally, I'm not sure that I even feel it needs to be split, but I can see some sense in having a comparison of the actual programming languages as a separate issue from their runtime implementations and APIs, legal and technical availability on different operating systems, and so-on. In general, I object to your idea of trying to find ways to back-shelf and lobotomize anything/everything that you feel is a criticism of Java, from editing sentences so that they basically make no sense because their base assertions actually follow their conclusion or other key factual aspects have been gutted, to arbitrarily deciding that a section on runtime market share belongs at the bottom of an article because Java's runtime availability is a sore spot, to deciding that no article should contain anything about Java that offends you at all because it should all be moved into its own "criticism of Java" article. I strongly object to this tactic. I feel it's a censorship tactic. I feel it's a threat to quality, and I feel it isn't workable here, or wiki-wide, or in any journalistic setting. Maybe we should have a "praise of Java," article where every point that you consider positive is stowed, and then we can leave the rest in coherent and pertinent places in corresponding articles. You don't start a newspaper, have a fine print page at the back called "things that angry people didn't want us to print," and then thoroughly censor the rest of the paper. 24.65.79.192 16:13, 18 April 2007 (UTC)

I think you fail to understand that the nature of Wikipedia articles is that they are not supposed to be conclusion forming. For this reason they do tend to be rather diluted and 'fence sitting' when it comes to controversial matters. This is the nature of the beast. Clearly you have very very strong views on aspects of Java. Clearly you wish to have your views expressed. Clearly you react against any attempt to dilute them. And clearly you're now reading political significance into simple matters like the ordering of sections (I added the section to the end because appending is the 'natural' thing one does when new material doesn't immediately appear to have an obvious home elsewhere.)

Far from trying to silence your anti-Java criticism, the notion of creating (or rather, using the existing) "Criticism of Java" was to give you an appropriate space where Java flaws and issues could be detailed at length. This article (C# vs Java) could then link off to that critique at frequent points throughout its text. Indeed other Java articles could also link off to the critique article -- giving your views even more exposure than they would have had as way-off-topic comments at the tail end of an language comparison article like this one. BUT!!!... this would only be fair if a companion article was created to allow critique of C#/.Net/Mono also. JavaKid 10:08, 19 April 2007 (UTC)

Or even split between "Comparison of C Sharp and Java", and "Comparison of .NET and Java platforms", because I think that almost all the "political" discussions are about the latter, and concern the platforms, not the languages. The first should help to understand the differences between the languages in a "programmer point of view", the second would need to discuss the strategies of Sun and Microsoft. Hervegirod 00:41, 19 April 2007 (UTC)

Right, I think we're talking the same language here, that makes sense to me. I do have a few concerns. One is that I kind of have the aching feeling that this is all motivated by a desire to bury facts that don't reflect well on Java. Also, if this article continues to include any discussion of APIs or community/usage patterns then that will logically lead to comparisons involving proprietary and free software, availability on different platforms, and many of the friction-generating topics. Also, the title "Comparison of .NET and Java platforms" would probably work, but I feel it sounds like it's referring only to the proprietary versions. Personally, though, while I strongly dislike the idea of burying anything "negative" about Java in a "criticism of Java" article, I think that your proposal sounds fine, so long as this article is limited to a present (not historical as that raises political issues) comparison of only the language syntax, not usage patterns or communities, not runtimes, not APIs, not availability under different platforms and licenses, etc.. (basically section 1), and everything else is moved as a whole, in tact, and in the same organizational structure to a new article. Basically, I feel the move shouldn't involve any edits, let alone reworking (destroying) the existing non-syntax portion of the article and its various points about each platform. 24.65.79.192 01:52, 19 April 2007 (UTC)

I have to agree with JavaKid that some API discussion can be relevant here – explaining the impact the introduction of generics had on the collection classes of both platforms for example – and shouldn't be moved to another article. This is why I initially suggested .NET and Java platform deployment as the title of the split-off article. I don't care much for the current Criticism of Java article though, as it attracts all sorts of uninformed and irrelevant criticisms and often even fails to accurately describe some of the valid criticisms. (The pitfalls of checked exceptions for example are described far more accurately in this article than they are over there...) I certainly don't think we should create a Criticism of .NET counterpart, or at least not as a split-off from this article. Most of the "political discussion" we all seem to be talking about is about the availability (or deployment) of .NET and Java on various systems. It doesn't really discuss differences between the two in terms of the API and for example how their support for third-party programming languages is, even though that's exactly what a title like Comparison of .NET and Java platforms suggests it would describe. And if that stuff was actually added, you'd probably want to move out the "politics" to yet another article... – Chip Zero 14:11, 19 April 2007 (UTC)

A general point about the impact of generics on APIs would probably be pretty harmless, but any attempt to actually document available APIs would open a whole can of worms related to standardization, like whether you document only what the proprietary platforms offer, whether you discuss which platforms have access to which APIs and the 'political' reasons why, and so-on. Really, the discussion of APIs in section 1 (such as in the context of generics) seems to be pretty neutral and not prone to political concern. I'm also not sure that the section of recent dispute called "Runtime inclusion in operating systems" is really the only point of friction, it just happens to have been a Java evangelist's focus over the last few days, but they mentioned wanting to censor a variety of facts throughout the article that reflect negatively on Java's license and other factors. Also, JavaKid has taken it upon themself to split off the article leaving a variety of non-language content in tact, and moving the particularly "anti-Java" parts to a new comparison of platforms article, and of course, just as I had predicted, the moved content was thoroughly gutted and sanitized for Java's sake in the process, conveniently leaving no record but the move between articles. I've reverted the edit in this article and moved the entire non-language portion (lower sections) to the article Comparison of the Java and .Net platforms. Other than putting the see also links into one article or the other, I didn't make any edits including rearranging sections and so-on in the process, and I don't think that would've been reasonable for me to do, as it limits the ability of other editors to clearly track and compare those edits. 24.65.79.192 17:01, 19 April 2007 (UTC)

I think it is clear that 24.65 will revert any change which isn't 100% to his liking, and generally will not accept any wording or fact which does not agree with how he 'feels' the world should be (even when cites are given to the contrary) under the vague banner of POV. Always unqualified. Attempts to dilute the wording, or find a diplomatic phrasing have likewise proved fruitless. ***EVERY*** edit is seen as some Machiavellian attempt to promote Java, or hide its weaknesses (ironically even edits which include criticism of Java.) While I'm not big headed enough to claim my edit was perfect, I worked very very very hard to prune the originating article so that the overviews left behind did not favour unduly one side or the other -- even going as far as to count the number of pro and con points in each section, and the amount of prose in each, to ensure they balanced out as best as possible. 24.65 (who regrettably seems far more fond of the REVERT button than he does the EDIT one) naturally sees it all as a clandestine attempt to skew the argument. In light of the recent uncooperative edit history of this article it has to be assumed that every edit, by whomever, will be aggressively scrutinised by 24.65, and reverted (as POV, without specific qualification of what and why) if they do not meet his expectations. As such, and in the spirit of trying to avoid unnecessary conflict, can I propose we merely leave 24.65 to it, and abandon edits of this article for the time being..? (Again -- I'm not angry, just a little frustrated that there seems to be this one person standing in the way of a mutually agreeable solution, no matter how hard some of us have tried!) JavaKid 14:25, 20 April 2007 (UTC)

PS: Of course, now I'll get accused of trying to slant the argument in a pro-Java way  :) JavaKid 14:51, 20 April 2007 (UTC)

I think I made my main objection pretty clear, and that is that making massive edits, or any edits to any article while it's in your hands during a move will give you special unchecked editing access that robs other editors of the tools to compare and monitor your edits. I also don't feel that picking and choosing the non-language portions of the article to move is consistent with the talk. I also don't feel that the article necessarily has to be "balanced" in the sense of having an equal number of points that would seem to refer to technical or legal or logistical reasons to use or not to use a given platform, because they may literally not stack up equally. I would say for every aspect of a given platform that you cover, the other should be covered too, but not all platforms are created equal. For example, C# has been standardized, Java hasn't, and I have 0 objection to getting into complete detail about both platforms on that subject, but I oppose the idea that Java must be made to somehow look like it's standardized too because otherwise it would seem like C# is being praised and Java is being criticized, because that simply wouldn't be factual. Also, "attempts to dilute the wording, or find a diplomatic phrasing," in my opinion, is referring to taking hard facts contributed by other people (many contributed by me in the first place, using the edit button) and actually damaging them, making them difficult to comprehend, or removing the information entirely, and with no motive other than the insistence that Java must be sheltered from "criticism." Either way, though, if you, in particular, have decided that you don't want to make edits, I think that's wonderful. Wikipedia does not need spin control, it does not need to be scanned and cleaned for facts that seem to be too "harsh" and going into "bloody detail" on a subject dear to peoples hearts, having any such content, whether pertinent and journalistic or not, moved to "Criticism of *" articles or simply oblivion. I resent every tactic you've undertaken, from rewording sentences in ways that degrade the logic because you feel the "positives" should come first even if it's not a logical structure, to moving around sections because you feel the "negative" ones should be at the bottom, to moving an article and making massive edits in the process that others are unable monitor or reverse, and all motivated by nothing useful to wikipedia, but rather a desire to destroy good journalistic facts and article quality in the name of sanitizing so that hard facts that reflect badly on Java will be hidden or removed. I will continue to revert YOUR edits, if they contribute absolutely nothing, and are at best represented as somehow improving readability, when in fact they do the opposite of that, too. If you'd like to go the way of mediation, that's fine and perhaps necessary, but I'm not open to working with spin and making sure the number of "negative" HARD FACTS about Java doesn't exceed a certain number, or level of detail, or any other arbitrary limitation, and I suspect you'll find that if push comes to shove, you have no recourse for playing spin doctor here. Wikipedia articles contain facts that some people don't like, even detailed facts that may be downright embarrassing (ever looked at George W. Bush?). The criteria are pertinence and verifiability, which aren't your points of concern, and aren't your basis for trying to remove or lobotomize informational content. 24.65.79.192 17:09, 20 April 2007 (UTC)

[I think it's about time someone asked for the help of the administrators, no?]

So let us sum up: You don't believe that articles should be balanced. You don't believe that Java and .NET should be represented equally. You don't believe in diplomatic wording. It is impossible to split an article without rewording sections of it, in order for both the new article and the original to make sense. Let me talk about hard facts: when editing the article I found examples of supporting citations which didn't even remotely back up the claim they were making. For example, a claim that Language X has a *significant* lead over Language Y on Linux was backed up by a page which merely listed a few dozen software programs write using Language X. Hardly proof. And that wasn't the only example. Now, *you* would have screamed "POV!" "POV!" and immediately reverted the page. I, being pragmatic, reworded the text to say Language X might have a lead over Language Y, and added a comment asking for a better ciration.

I had to move sections relating to lanuage back into this article because you have left the new article in such a mess. You'd just cut/paste material on an article about the C# language into an article about the .NET platform, and left it unedited.

It is clear that you take a very dim view of Java, and it is clear that you have a high opinion of C# (and/or Mono.) It is clear that you consider your views to be the truth and that you consider other views to be POV. It is clear that you want these articles to reflect those views. This would not be a problem, if you provided some *hard fact* (real hard fact, with cites -- not your 'gut feelings'.) Until then, the article will continue to favour neither one side nor the other. You may not like the fact that your extended commentary on Java's failings is counterpointed by some material on Java's successes. You may not like the fact that Mono's successes is counterpointed by some material on areas where is is lacking. You may not like the fact that you can't say X is better/more popular/more stable/easier than Y without independent citations to back it up... but then in life we don't always get what we want  ;) JavaKid 19:20, 20 April 2007 (UTC)

I believe that articles should have balanced coverage of all pertinent and verifiable facts, covering all sides of a subject. I believe that wording should simply stick to the facts, with no positive or negative commentary added to support or oppose a given side of the issue. I believe that the only valid edits are those aimed at providing information, removing falsehoods, and improving quality and readability. I believe it's unreasonable to expect coverage of a subject to reflect equally well on all sides. Sometimes, you have situations where the facts don't reflect well on one factor or another. In this case, for example, C# and the CLI have been standardized by processes beyond Microsoft's administrative control, but Java hasn't been, and there's no rule or reason in wikipedia why the article should try to spin that fact to make it seem like both languages and ABIs have been equally standardized. My personal stance is that I will continue to revert edits that seem to serve no quality of information (verifiability, new info etc..) purpose, and no quality of writing (logical structure, being as concise as possible, etc..) purpose. I also oppose the practice of making edits during the move of information while splitting an article. If changes must be made for logical reasons then I think it's better to move the information verbatim and then make the changes afterward so that other editors can see what you did. As always, I'm not sure what else to do but to try to explain myself clearly, and to continue to reverse any edits that serve no quality or informational purpose. If you want to seek mediation, that's fine with me, I think the rules and intent of wikipedia are on my side here, and you'll find that this concept that all articles must reflect well on all sides in all ways, and any unpleasant facts must be removed, is not a part of wikipedia. 24.65.79.192 19:46, 20 April 2007 (UTC)

The facts you are forbidding to be added are valid. Your heavy use of the major reverts is once *again* in effect.  :( Before this issue becomes serious I will ask someone a little more senior to review the conduct on all sides. Then perhaps we can get back to actually creating a balanced, useful, article? Please be patient. JavaKid 19:57, 20 April 2007 (UTC)

I'm not sure which facts you mean. For the most part, your stated goal here seems to have been eliminating anything that you see as being too much "gory" detail about possible issues relating to Java. For example, to quote you, Java woes, its legal status, its deployment, etc etc etc, were covered in gory detail at multiple points in the text. While all these points are PERFECTLY VALID (and indeed highly worthy of note) the disproportionate amount of coverage coupled with the anal amount of detail was totally off the scale. I mean, whether one agrees or disagrees with that sentiment, the point is that the issue here isn't that I want to keep out facts, it's that I want to keep them in. You did mention a couple new facts that were previously omitted, like the fact that Mac OS X doesn't include Mono, and I happily added them. Anyway, mediation sounds good to me, and I have no changes that I'm trying to push here, so there's no issue related to leaving the article with all of its facts as they appeared before this conflict, and waiting for mediation, as far as I'm concerned. 24.65.79.192 20:11, 20 April 2007 (UTC)

I have not deleted facts, only added counter arguments, and further information (with cites if necessary.) Sometimes statements are made and the references do not bear them out - for example a claim that C#/Mono is 'specifically' more popular than Java; backed only be a list of a few dozen C# applications. Or a claim that Mono is available pre-installed on many operating systems, with a reference merely listing the platforms it has been successfuly compiled on. In such cases anyone should by rights strike the claim -- but I prefer to neutralise it a little ("C# may be more popular" instead of "C# is significantly more popular") and leave a comment asking for clarification. Note: this is significantly more generous and pragmatic than the stance you take. While you seem to revert other people's edits with gay abandon (indeed you seem to do nothing but, of late) I generally hate touching other people's material unless I'm super confident of the facts and can point to something to prove it. I prefer to add counter claim to balance an article rather than viciously attack and nit pick points already made. When I did the article split I spent a whole lot of time trying not to unbalance the text by removing too much on one side and not the other. And everthing I removed from the original article ended up in the new article, re-drafted to refer to .NET and not C#, with the exception of a comment about Visual Studio and two citations which could not be converted from C# to .NET. Of course, if I was cynical I might wonder if you even bothered to read my new stuff before you went into "REVERT REVERT REVERT" mode. I hope you did.  :( JavaKid 22:10, 20 April 2007 (UTC)

The references in the mention of pre-installed mono are articles that state mono is included in those operating system. Also, removing a claim because it isn't referenced, or isn't properly referenced, (though it is properly referenced here) is not good policy. Unverifiable or provably false claims should be removed, but unverified claims should be investigated. Also, again, I have no objection to your adding new verifiable facts. You pointed out that Mac OS X doesn't include Mono, I happily added that fact. The issue here hasn't been about verifiability, though, and there is a record to that effect. You've left an editing history of comments and changes to the article(s) that clearly demonstrate a desire to "dilute the wording" of "gory" and "anal" detailing of "PERFECTLY VALID" and "highly worthy of note" facts (you words are in quotes). That is the problem, that is my objection, and I think your agenda is way outside of any journalistic or constructive policy here. 24.65.79.192 22:23, 20 April 2007 (UTC)

At the foot of this page you'll see the RFC, calling a 'grown up' (ho ho!) over to take a look at this dispute. I have a heavy heart about this. It is the first time I've ever had to do it, and to me it smacks of failure. But in the end I realised it had to be done if the article was ever to be free from tit-for-tat edits, and it had to be done quickly! Apparently (so the documentation stated) the conduct of everyone in the dispute is scrutinised, which isn't nice, but necessary I guess. I suppose everyone here has been guilty of getting a little steamed, although thankfully all the contributors managed to avoid turned it into a slanging match. But the important thing is that hopefully this independent overview of the little squabble will have a productive outcome -- namely, an article you, I, and everyone else can edit without excessive pedantic edits. I think I started in this dispute by asking for some pragmatism, and that continues to be my concern. Here's hoping...  :) JavaKid 22:10, 20 April 2007 (UTC)

PS. Thankyou for agreeing to let me add facts about the Mac, after reverting them so many times in the past I've lost track. Are there any other facts you are willing to allow in?  ;) <== Smiley JavaKid 22:14, 20 April 2007 (UTC)

I've never had an objection to adding facts. This has been a conflict over whether it's valid to "dilute the wording" (and much more than wording) of "PERFECTLY VALID" and "highly worthy of note" facts that cover "Java woes" in "gory detail." 24.65.79.192 22:27, 20 April 2007 (UTC)

Split this article: how to divide the article, and what to name it

I didn't notice it at the time, but just ten minutes before my latest post in the discussion of how (and if) to split this article, this article was already split-off as Comparison of the Java and .Net platforms. While I have no problem with that, and agree it needed to be done at some point or another, we still need to give the article a proper name. I suggested .NET and Java platform deployment. Other suggestions were Comparison of CLI and Java runtimes or Comparison of .NET and Java platforms. Problem with those titles is that they seem to suggest an in-depth comparison of the workings of the platforms and frameworks, while the current article is mainly about the availability on various systems and the licensing conditions surrounding this. (But at least they are better than the name it has right now.) During the previous discussion some rough sketches were made about what to include and what not to include in the new article. Like JavaKid, I think that the discussion of the language evolution, and the "market place" section need to be included in the present article,[10] since they concern the language and not the frameworks or platforms. I would like to have your feedback on this, and would appreciate it if it could happen this time without sidetracking to (wild) accusations of sockpuppeting or discussions about reverted edits. While these may be issues worthy of discussion, please keep it to other sections or personal talk pages. – Chip Zero 22:52, 20 April 2007 (UTC)

Personally, I like the idea of having an article that is nothing but 'mathematical' facts that can be verified by consulting language specifications. Like a legal summary, with no need for any "soft science." I might propose a third article titled "Historical relationship between C# and Java," and maybe another titled "Comparison of C# and Java communities." I mean, I'm not saying these are invalid topics, I just find them a little touchy-feely/pseudo-verifiable, compared to hard facts about syntax. I do see what you mean about the title suggesting a technical comparison between runtimes when it's really a deployment, licensing, and community comparison. How about "Comparison of .NET and Java usage"? 24.65.79.192 22:59, 20 April 2007 (UTC)

I wouldn't exactly call the language discussion "mathematical". It has a long history of small disputes and revisions that describe one to sound just a little better than the other. There's always some friction in what details to include and what to leave out. Most things aren't absolute, such as the merits of having or not having checked exceptions. Same story for generics, where the (obvious and huge) problems of Java generics are getting a lot of attention right now. But there is no mention of the fact that the Java approach provides more constraint options (super and wildcards; another double-edged sword) and provided the much-needed backwards-compatibility with the large collections API. But you're right, the language sections seem to have mostly stabilized now, and for some reason the focus lately has just been on the nether regions of the article. Anyway, as mentioned below I would like to keep most of the evolution/history section in here, and move the rest of the runtime and product details to the other article. I think Comparison of .NET and Java usage is one of the better titles suggested yet, so that might be an idea. Keep in mind that we're not really stuck with "comparison of" though. – Chip Zero 10:01, 21 April 2007 (UTC)

I think the evolution section clearly belongs here, as it concerns the language proper. However, I think the marketplace section should be moved to the new article, because it is not a fact about the language, but is instead concerned with the relative success or failure or the platforms. Just to be clear, by platform I do not mean the specific technical components of the JVM and the CLR, respectively, but instead the Java and .NET as products rather than as pure technology. I think, although I am not sure, that this corresponds with 24.65's and JavaKid's understandings of this issue, but they should speak up if I misunderstand their views. Chip Zero, could elaborate a little bit more on how you would like to split up the article? I think perhaps a better name for the new article would be Comparison of the .NET and Java Platforms, and we could possibly rename the parent article Comparison of C Sharp and Java (language). Tbjablin 02:00, 21 April 2007 (UTC)

The current marketplace section is a mixed bunch of statements, that compares C# to other languages and provides a bit of history and describes its links to the J# language and product. I suppose most of it could be integrated into the 'evolution' section. On the other hand "marketplace" also compares .NET to the JRE, and even actually describes the marketplace conditions a bit. Those last bits clearly don't belong here, and would be better suited in the other article. About your title suggestions, imho the current title of this article is fine, and should already reflect that it's about the languages. For the other article, I think we need something more specific; calling it a comparison of the "platforms" is just to broad. – Chip Zero 10:01, 21 April 2007 (UTC)

Runtime market share

I think it would be simpler and more accurate to say that GNU Classpath has complete support for Java 1.4 (99.97% !!), but the 1.5 evolutions of the language are still under development (generics, for example), and Mono complete support for the core 2.0 class libraries (those that are standardized) + incomplete support for the other supporting libraries (ADO.NET 2.0, ASP.NET 2.0, Forms 2.0, XML 2.0,...). I know that we already talked about that... Hervegirod 23:47, 15 April 2007 (UTC)

Tbjablin's edits

I'm reverting your (Tbjablin's) edits again. My two major concerns are as follows:

• No new facts have been added. What you're apparently calling a fact is actually stating a fallacy. Yes, it's a fact that some operating systems that use the Linux kernel and various GNU programs also include non-free software such as closed source video drivers and the flash plugin, no dispute there. However, those are not, by definition, free software operating systems. They may include free software components, just as Microsoft Windows does (libpng etc..) and they may even use a free software kernel (or mostly, if you don't count closed video drivers that taint the GPL) but they are not free software platforms, they're a mix. Mac OS X also uses some GNU components, though the kernel is pseudo-free, and a good portion of the user level components are closed source and aggressively proprietary. The simple and natural definition of a free software operating system is an operating system that is free software, such as the core distribution of debian or fedora, but unlike suse enterprise, mac os x, or windows. Also, keep in mind that free software as defined by the free software foundation and GNU isn't just copylefted software, GNU, or Linux. Anything that is 'open source' and has a sufficiently permissive license is free software, including BSD and other non-Linux free software operating systems. The key point that you're mistakenly erasing is that Sun Java is not open source, or free software, and there it can only be included in a mish-mash or entirely proprietary operating system that can't be accurately described as free software because of the proprietary components.

Can you name any actual free software operating systems in the real world? I don't think any exist. Operating systems which do not exist do not include Java by definition. Tbjablin

I named two, fedora core and debian core. As far as I know, the fedora project doesn't support the use of non-free components at all, even in their extras repo. Personally, I've had free-software-only linux cds (starting with slackware, which is also free-only in the core OS), dvds, and installs on my machines for over a decade. 24.65.79.192 08:27, 16 April 2007 (UTC)

But Slackware and Debian (don't know about Fedora) include Java in their extra repositories even though they are not part of the default install. This seems to be an important fact worth mentioning. Tbjablin 08:32, 16 April 2007 (UTC)

• The rearranging doesn't seem to serve any purpose. I'm not sure why Java has been bumped up, and I don't see why the comment that you moved into the desktop application area is necessarily any more pertinent there than in a section about runtime availability. The point is actually more about the availability of runtimes and the possibilities that are afforded as a result than it is about anything desktop-specific. If anything, I would remove the word desktop from the point.

As it stands now the organization of the paragraphs seems confused. If you want to put .NET first, that's fine with me, but I think it should be organized by topic. The statement is about desktop applications that actually exist and not about deployment of runtimes and therefore should be placed under the description of desktop applications and not under the deployment section. Tbjablin 08:18, 16 April 2007 (UTC)

It took two mouse clicks and 14 backspace presses to moot the point about moving the application development point else. I do see your point about covering Java and then C#, though I'm not sure why you placed the windows mention above the free software mention. 24.65.79.192 08:27, 16 April 2007 (UTC)

I don't quite understand your point about 14 backspaces. What was backspace? I generally like to place things in order of commonality and Windows has a greater installed base and hence is more common than Linux or OSX. So, I would therefore place it first. Is there any reason why Linux should be first? Tbjablin 08:36, 16 April 2007 (UTC)

However, I do see your point on renaming the section, because it is primarily about runtime inclusion in various operating systems, and doesn't even get into any statistics about the number of machines that have a CLI or Java compatible runtime installed. On the previous subject of linux not being "mainstream", linux actually has over 3% of the world desktop market, as compared with Apple's 2-point-something. I also appreciate that you've accommodated some of my previous concerns, and I'm sure we can find some middle ground here.

I'm not the person who said Linux was not mainstream. You are thinking of another contributer. I always post under this username. Tbjablin 08:18, 16 April 2007 (UTC)

Anyway, because the edits seem to be serving no informative purpose or intent, and, at least in my opinion, they provably degrade the quality of the article, I'm reverting again, but this time I'll restore some of the changes and hopefully I can address your concerns and move toward a working solution.

- 24.65.79.192 08:05, 16 April 2007 (UTC)

Anyway, I think you will find that my edits have not removed any content, only rearranged it slightly. I have re-included the sentence about free software operating systems, even though I am skeptical that such things exist. The original ordering of the paragraphs had no internal logic. It seems to me that the paragraphs should be grouped by platform (Java/.NET) or by OS (Windows/Linux/OSX/BSD). On a somewhat unrelated note, please register so you will be easier to identify when your IP changes. Tbjablin 08:30, 16 April 2007 (UTC)

You're still responding under a misconception of the point. I'm guessing you've never used a free software operating, which is fine, but you're deeply underscoring an ignorance of the subject. Some (many) of us actually value being able to edit and compile our own operating system. For many, it's the reason for using Linux, and it's why we resent and refuse to load Sun Java. For some, Linux is about a free ride, and that's fine, good for them, but you're grossly underestimating the significance of the free software movement here. Your edits are still not responding to this issue, and you still think a logical response on your part is proving that some operating system somewhere includes both a free software and a proprietary component. I could name probably 50 examples for you off the top of my head if you have some need for off-topic and pointless references, but it really means nothing. You'd might as well cite Windows by pointing to some sources that demonstrate windows includes some free software components or libraries.24.65.79.192 08:41, 16 April 2007 (UTC)

I have a pretty good understanding of FOSS, and I use Linux, although you would likely consider me a pragmatist. I acknowledge that there are free software purists of which you appear to be one. It is nevertheless the case that the most popular Linux distributions, (subjectively Debian, Ubuntu, Slackware, Fedora, Mandriva, and OpenSUSE) mostly include Java. I think that the article should say that many (perhaps most) important Linux distributions include Java, but should also say that FS OSs necessarily do not. I think that accurately reflects the facts of the matter. Tbjablin 08:51, 16 April 2007 (UTC)

I think you're confusing a core distribution with an extras or proprietary repo, and possibly an official distribution with a third-party package set, and maybe even classpath with Sun Java. You also seem to be glossing over Fedora (isn't it the most popular now?), Gentoo, and many other distributions that don't distribute or support any proprietary components in any way. 24.65.79.192 09:14, 16 April 2007 (UTC)

Please sign your posts. Check the links they are all from official extra repositories and they are all labeled as Sun. (As opposed to unofficial extra repos like Debian backports.) This question of which Linux distro is most popular is incredibly hard to measure, varies wildly with geography, and is ultimately irrelevant. Tbjablin 09:11, 16 April 2007 (UTC)

Either way, the list of Linux maintainers that provide a non-free repo is there now. 24.65.79.192 09:14, 16 April 2007 (UTC)

You've also ignored my point and attempt to address your concern about the cross-compatibility statement. I updated the statement, it didn't contain the word desktop, there's no apparent reason why it would/should, and there's no reason why you would restore the word desktop and move it into the desktop section again. 24.65.79.192 08:41, 16 April 2007 (UTC)

I need more context. What are you talking about? Tbjablin 08:52, 16 April 2007 (UTC)

You said that the statement about desktop applications belongs in the desktop section. My response was that it's not a point about desktop applications, but rather a point about the write-once-run-everywhere effect of having .NET in Windows and Mono in the core distributions of many free operating systems. In response to the subject, I simply removed the word desktop from the sentence in the article (otherwise leaving it verbatim), and it still made as much sense and was as pertinent to the existing placement. 24.65.79.192 08:56, 16 April 2007 (UTC)

Anyway, I'm reverting again, and then restoring your sectioning, because I have to agree that there is a logic to it, and I'm not trying to lock you out here. 08:41, 16 April 2007 (UTC)

Also, while you are definitely censoring the point that free software operating systems (such as you would find on a core debian, fedora, ubuntu, gentoo, slackware etc.. disc/install) are incompatible with Sun Java, I did add a mention (that you reverted without explanation) of the fact that some platforms that contain both free and non-free components do include Sun components. I have no objection to a mention of that fact, but it is a fact that free-only operating systems are common, they probably represent a good portion or even a majority of linux media sales and OS installs, and they are incompatible with Sun Java. 08:46, 16 April 2007 (UTC)

Dude, I left in that point, I censor nothing. Tbjablin 08:53, 16 April 2007 (UTC)

At least five?

So, "at least five" seems a bit POV. Whether or not non-free including distros are a numerical majority, they do include Slackware, Mandriva, Linspire, Debian, and Ubuntu. I'm not sure about Gentoo, Freespire, Fedora, and RedHat. Knoppix doesn't count. So, something like half of the important distros today include Java in non-free official repos. This appears to be a common practice. Your editing of the article makes a common practice appear to be extremely uncommon. Tbjablin 09:32, 16 April 2007 (UTC)

It is a fairly common practice, but you need to be able to demonstrate that fact. I don't know how to verify (or define) whether "many" Linux maintainers do it, or which are "major," and unless you can provide a way to verify those claims, they don't belong in a wikipedia article. I said at least five because you cited at least five. If you can cite some credible statistics then that would be fine. You could also add more and more references. Personally, I say the easiest thing to do is just stick to an easily verifiable fact, that "some do." 24.65.79.192 09:46, 16 April 2007 (UTC)

I think you are just using verifiability as a pretext to squash what you know is true. Nobody knows which Linux distro is in the lead so to speak, but everyone knows that it has to be one of Slackware, Mandriva, Linspire, Debian, Ubuntu, Gentoo, Freespire, Fedora, RedHat, and Knoppix, because those distros collectively have a vast majority of the mindshare. Any sort of reasonable comparison, (ie number of books, number of Google hits, etc) will basically support this thesis. However, I am willing to settle with several. Tbjablin 10:02, 16 April 2007 (UTC)

I agreed that it's a common practice. I'm not refuting your estimate, but I've had to censor many of my own estimates on wikipedia, and in many cases even obvious and self-evident truths, because it is supposed to be journalistic and completely verifiable. Though, there are definitely times when I'm glad that "everyone knows" doesn't cut it (ad populum is a fallacy after all), though this isn't necessarily one of them. Several is fine with me, too. 24.65.79.192 10:13, 16 April 2007 (UTC)

Runtime inclusion

The text for Mono (C#) and Classpath (Java) is different, although their situation is the same: for Mono: "Both Microsoft .NET and the Mono project have complete support for the Ecma- and ISO-standardized C# language and runtime...As a result of inclusion of .NET or Mono runtimes in the official distributions of many operating systems, applications that utilize the programming interfaces that are common to both .NET and Mono can be developed in C# and then deployed across many operating systems...". For Classpath: "has limited compatibility with the current version of Sun Java, and may be unable to act as a runtime environment for Java programs that utilize new features in the current version of Java". Classpath is compatible with Java 1.4, but not Java 5.0 or Java 6, and Mono is compatible with the core 2.0 class libraries but not with .NET 3.0, nor many 2.0 supporting libraries (ADO.NET, ASP.NET, Forms, XML,...). So it is also true that Mono "has limited compatibility with the current version of Microsoft .NET, and may be unable to act as a runtime environment for .NET programs that utilize new features in the current version of .NET". Hervegirod 23:32, 16 April 2007 (UTC)

They're two separate points. The point about Windows providing .NET, and free software operating systems providing some of the same features by way of Mono has no analog with Java because Microsoft doesn't bundle Java with Windows. The simple fact is that Java is not part of the Windows distribution system, and there's no point to be made about having a Java runtime available in that share of the market. The C# portion does state "but each environment includes many components that have not been implemented in the other," and while the wording may be a little different, that is the analog to the point that free software operating systems simply don't have access to recent Sun Java features. I think it's made clear in both sections that free software runtime projects currently don't provide everything that the proprietary versions do, but it is a somewhat different description for C#, partially because Mono has a life of its own, and the project's goal isn't simply to replicate .NET, but rather to provide its own original interfaces as well. 24.65.79.192 00:34, 17 April 2007 (UTC)

I have changed the ordering of the paragraphs in the C# and Java sections in order to highlight the parallels. Tbjablin 00:49, 17 April 2007 (UTC)

Makes sense and looks good to me. 24.65.79.192 00:57, 17 April 2007 (UTC)

In general, if you're going to remove something for being POV, it can be a good idea to give some explanation. Why do you feel that The incompatibility between Sun Java and free software means that free software operating systems can not include a runtime that is compatible with modern Sun Java because the closest-to-compatible is POV? 24.65.79.192 00:58, 17 April 2007 (UTC)

Imagine if I wrote:

• The incompatibility between the Microsoft .NET Runtime and free software means that free software operating systems can not include a runtime that is compatible with modern C# because the closest-to-compatible free software alternative, Mono, is 99% compatible with the core 2.0 class libraries but has limited compatibility with current version .NET 3.0, nor many 2.0 supporting libraries (ADO.NET, ASP.NET, Forms, XML,...), and may be unable to act as a runtime environment for C# programs that utilize new features in the current version of .NET.

Tbjablin 01:02, 17 April 2007 (UTC)

If you can convey that information without erasing existing facts like the fact that Mono also has unique APIs, and you can cite references, and you change "modern C#" to "modern .NET" or better yet "the current version of Microsoft .NET," then it will be a legitimate verifiable edit, and not subject to a POV complaint, though others still might apply. 24.65.79.192 01:05, 17 April 2007 (UTC)

The fundamental problem is that neither Java nor C# have entirely satisfactory Linux implementations. C# proprietary license is never mentioned nor is the lack of an MS runtime for Linux, but Java gets whipped repeatedly for providing an opensource, but not free software runtime for Linux. GNU Classpath is damned as having "limited compatibility," but Mono is described as "hav[ing] complete support." Tbjablin 01:11, 17 April 2007 (UTC)

Actually, Microsoft has a shared source version of .NET called rotor, but unlike Sun, Microsoft doesn't pretend to be embracing free software. .NET's incompatibility with free software is basically just implicit, there's no corporate propaganda to disprove here. However, if you think there may be any confusion, or it's just good practice to be complete, feel free to point out that Microsoft .NET isn't compatible with free software. Unlike Sun Java fans, nobody in the .NET camp is going to have any delusions shattered by that fact. Also, if you can find some comparable statistics about .NET and Mono to the Sun Java and Classpath completeness figures, post them, but it's probably not appropriate for quality reasons to manually document component lists here. There is a mention already of the fact that each runtime has components that the other does not support, but it's harder to go beyond that with C# because Mono has a whole bunch of unique APIs that .NET lacks, and because, at least as far as I've seen, the same direct summary figures aren't available. 24.65.79.192 01:23, 17 April 2007 (UTC)

So basically, it is important to bash Sun because there may be some deluded individual who confuses open source with free software, and also because Sun is somehow being disingenuous? I think Sun's policy has basically been clear since day one (that Java was there baby to do with as they liked although they might at there discretion play nicely with others). Tbjablin 01:31, 17 April 2007 (UTC)

I thought common was a legitimate edit. I'm sorry that you thought it was an attempt to prove a point. I meant it as a sincere edit. Also, you're the one who has actually broken the 3-RR.

• 21:31, April 16, 2007 24.65.79.192 (Talk) (revert because: you've broken the three-revert rule about classpath compatibility, still with no reason given on why it's "POV", and moving 'popular' from C# to Java to make a point is a no-no too) <- Revert 3!!
• 21:21, April 16, 2007 Tbjablin (Talk | contribs) (Common less POV than popular)
• 21:20, April 16, 2007 Tbjablin (Talk | contribs) (Under C# three distros == popular)
• 21:18, April 16, 2007 Tbjablin (Talk | contribs) (More reasonable) <- Revert 2
• 21:03, April 16, 2007 24.65.79.192 (Talk) (→Java - trying again to convey the facts without adding commentary or speculation, though it's difficult to adapt to reversions that do not include a specific complaint) <- Revert 2
• 20:56, April 16, 2007 Tbjablin (Talk | contribs) (That's even more POV than the original.) <- Revert 1
• 20:54, April 16, 2007 24.65.79.192 (Talk) (→C# - I see your point that the previous order had a sentence trailing a mention of Linux/BSD inclusion where it didn't belong, but I think the same is true with the new order. how about this?)
• 20:51, April 16, 2007 24.65.79.192 (Talk) (→Java - I understand your point, but you've erased a driving concept here. I'll try to phrase it in a more objective way.) <-Revert 1
• 20:48, April 16, 2007 Tbjablin (Talk | contribs) (Change order)
• 20:45, April 16, 2007 Tbjablin (Talk | contribs) (Sounds like POV) <- Original edit

Tbjablin 01:35, 17 April 2007 (UTC)

Also, further reading indicates that the 3-RR takes effect on the fourth revert, and also counts ALL reverts, not just reverts of the same line. So, I think if we were to apply this rule correctly then we have both violated it. Why don't we, in order to keep things civil, both agree not to edit the main page, and instead work here in discussion space, until Friday night. Tbjablin 01:47, 17 April 2007 (UTC)

Actually, you may have noticed that when I reverted your edits, I explained why, reincorporated various parts, and worked with you to resolve as many of your concerns as possible, like dividing the section into C# and Java, listing Linux distributions that include non-free software, etcetera.. The section now reflects a whole variety of your ideas and proposed changes. On the other hand, you haven't explained why my phrasing is supposedly POV, or why the factual information that I'm trying to convey there doesn't belong for some reason. 24.65.79.192 01:53, 17 April 2007 (UTC)

I have explained it a couple times, but I think you keep missing it, because it has been difficult to figure out what commentary describes which edit. Also, I think you may have found some of my explanations unsatisfactory. Regardless, looking at the 3-RR you will see that there is no exception for working for another person to resolve things, being reasonable, integrating edits, etc. Tbjablin 02:07, 17 April 2007 (UTC)

I actually only reverted your mass edits a total of 3 times, and one was on a previous day, so it's moot. Either way, my point is that if you want it to be anything but a reversion war, you need to actually make some move other than just silently reverting over and over, which I did, and you're not doing, that I've seen. I noticed that sentence where you asserted the sentence you want to remove is negative, but you haven't explained why your assertions are valid, like I asked, and I haven't seen any other explanation. In case I've missed something, can you lay out in complete and clear terms why you feel the sentence is POV? 24.65.79.192 02:13, 17 April 2007 (UTC)

I don't think you're applying the 3-RR correctly, you should read the article. Also, I feel like I've been working constructively to fix this (my edit summaries were generally fairly long and descriptive and I've been laying out a rational for my edits.) However, as a show of good faith, I will apologize and admit blame for for edits that were insufficiently justified, and for any aggravation, inconvenience, or defamement cause to you thereby. I think we are both putting forth a good faith effort to move the article closer to a more ideal state, and I hope that by moving our discussions from the article to discussion space, we can enjoy more amicable and productive relations in the future. Tbjablin 02:21, 17 April 2007 (UTC)

I'm not sure what summaries you're referring to. I've seen you refer to the sentence as POV and negative, and the order as POV and negative, but the problem here is that I feel the sentence is NPOV and pertinent, and you're not giving me any reason to think otherwise, beyond the idea that I might just accept your assertion that it's POV and negative without any explanation, or that I might accept the fact that you're so determined to edit the sentence out that I'll face an endless conflict if I don't just allow that. 24.65.79.192 02:28, 17 April 2007 (UTC)

Runtime inclusion in operating systems

C#

On Windows platforms, Microsoft is promoting C# as its flagship language, in part by including the .NET runtime in all recent Windows environments, and by distributing the Visual C# Express development environment at no cost.

C# and the CLI have recently become included and used in a number of Linux and BSD based operating systems by way of including the free software Mono Project. As a result of inclusion of .NET or Mono runtimes in the official distributions of many operating systems, applications that utilize the programming interfaces that are common to both .NET and Mono can be developed in C# and then deployed across many operating systems and processor architectures using a runtime environment that is available as a part of the operating system's installation.[11][12][13]

Both Microsoft .NET and the Mono project have complete support for the Ecma- and ISO-standardized C# language and runtime, and many of Microsoft's non-standardized .NET programming interfaces have been implemented or are under development in Mono,[14] but each environment includes many components that have not been implemented in the other.

Java

Windows does not currently ship with a Java runtime environment, however some OEMs pre-install the JRE on their desktop and laptop models. Apple's support for Java means it has come pre-installed on all new Apple computers since the launch of MacOS X.

Free software operating systems are currently unable to include any Sun Java Runtime Environment because Sun has not released its Java class library under a free software license. However, some operating systems that include both free and non-free software do contain Sun components. Additionally, several Linux maintainers distribute non-free components including Sun Java in official archives that are separated from their main operating system distribution, for example Debian non-free, Ubuntu multiverse, Slackware extra, OpenSuse non-OSS, and Mandriva.

The closest-to-compatible free software alternative, GNU Classpath, is 99% compatible with the 1.4 version of Sun Java, but has limited compatibility with the current version of Sun Java, and may be unable to act as a runtime environment for Java programs that utilize new features in the current version of Java. The fact that Sun Java is not free software combined with the incomplete state of GNU Classpath has the effect that free software operating systems cannot include a runtime environment that is compatible with current Sun Java.

The difficulty with this sentence as it stands now is that it uses overwhelmingly negatively connotations. The compatibility of Classpath is made to seem smaller by this ordering of facts. Tbjablin 01:57, 17 April 2007 (UTC)

Can you validate those assertions? 24.65.79.192 01:59, 17 April 2007 (UTC)

Quite easily, as a native speaker of English, I am well familiar with both the connotation and denotation of various statements in English. (How else does one validate the connotation of a statement?) Tbjablin 02:04, 17 April 2007 (UTC)

I don't really see what more I can do but try repeatedly to rephrase with absolutely no commentary, speculation, or unverifiable phrasing, like I did, and to ask you to explain what you mean by "POV" so that I can try to address and resolve this issue. I'm not sure how you expect to resolve it by treating this like a reversion war and silently editing out the same sentence over and over with no explanation given but calling it "POV" without stating why and pasting the sentence with Java changed to C# as your reason. 02:07, 17 April 2007 (UTC)

I've not been treating this as a revert war. I've never used the same version twice. I keep changing it trying to find one you find acceptable. Tbjablin 02:08, 17 April 2007 (UTC)

More troubling, do you honestly think that there is nothing POV about the current ordering? Or to put it another way, do you believe that my changes have any effect on the POV of the statement, and if not, why exactly are you reverting? Tbjablin 02:10, 17 April 2007 (UTC)

With regard to this sentence, I never restored the same version of the sentence twice, but you reverted to the same result each time. Also, re-adding is not reverting. And no, I'm not sure what the basis would even be to the idea that the ordering is somehow POV. It's hard for me to understand you when you don't attempt to actually just explain your concern. 24.65.79.192 02:16, 17 April 2007 (UTC)

I think you are basically wrong on the facts here as well, and browsing through the history will prove it, but for the purposes of amicable discussion, I'll stipulate that I did. Tbjablin 02:23, 17 April 2007 (UTC)

It's pretty easy to demonstrate, you edited the beginning of the sentence 3 times to remove a fact, and each time the result was "The closest-to-compatible free software alternative," 24.65.79.192 02:32, 17 April 2007 (UTC)

Let me try to explain this clearly from the beginning in using transparent reasoning and without resorting to arguments I have previously presented elsewhere.

• Argument:

• Question: What is the purpose of the previous paragraph?

• Answer: The purpose of the previous paragraph is to describe the current situation with regards to FS. It says that although Sun Java is incompatible with FS, it is nevertheless included in {many/common/several/evil/popular/a number of/five?} Linux distros.

• Question: What is the purpose of this paragraph?

• Answer: This paragraph introduces Java Classpath as an FS alternative to Sun, and comments on some of its weaknesses.

• Question: How does the paragraph read if the 24.65 {get a real username!} reading is used?
• Answer:

The fact that Sun Java is not free software negative claim has the effect that free software operating systems can not negative claim include a runtime environment that is compatible negative claim [technically a positive inside of a negative claim, but that's the same thing] with current negative claim Sun Java because the closest-to-compatible free software alternative, GNU classpath, is 99% compatible positive claim with the 1.4 version of Sun Java,[39] but has limited compatibility negative claim with the current version of Sun Java, and may be unable negative claim to act as a runtime environment for Java programs that utilize new negative claim features in the current version of Java.

• Question: How does the reading differ in the tbj rendering?

The closest-to-compatible free software alternative, GNU Classpath, is 99% compatible positive claim with the 1.4 version of Sun Java, but has limited compatibility with the current version of Sun Java, and may be unable negative claim to act as a runtime environment for Java programs that utilize new features negative claim in the current version of Java. The fact that Sun Java is not free software negative claim combined with the incomplete state negative claim of GNU Classpath has the effect that free software operating systems cannot negative claim include a runtime environment that is compatible negative claim with current negative claim Sun Java.

• Question: What's the difference? They have the same claims. Just a different ordering.
• Answer: Consider the sentences:

• The fact that Buchanan did nothing to stop the growing secessionist sentiment, despite his innovative foreign policy, makes him an unpopular president among historians (Imagine I have a citation for this).
• Buchanan is an unpopular president among historians, despite his innovative foreign policy, because he did nothing to stop the growing secessionist sentiment.
• Despite his innovative foreign policy, the fact that Buchanan did nothing to stop the growing secessionist sentiment, makes him an unpopular president among historians.
• Despite his innovative foreign policy, Buchanan is an unpopular president among historians, because he did nothing to stop the growing secessionist sentiment.
• The fact that Buchanan did nothing to stop the growing secessionist sentiment, makes him an unpopular president among historians, despite his innovative foreign policy.
• Buchanan is an unpopular president among historians, because he did nothing to stop the growing secessionist sentiment, despite his innovative foreign policy.

These sentences have different connotations:

• Sandwiching a positive claim between two negative claims makes it seem incidental.
• Placing a positive claim first contrasts it with the rest of the sentence.
• Placing a positive last also contrasts it with the rest of the sentence, but now the negative claims are made to seem normal and the positive claim exceptional.

Conclusion, if you have three facts of approximately equal importance two negative one positive, the most effective organization is with the positive claim first. otherwise it will be overwhelmed by the negative claims. (This may be desirable if the positive claim is much less important than the negative claim.) Tbjablin 03:13, 17 April 2007 (UTC)

• Assertion: The logical flow of an argument is from premises to conclusion.

Lemma: Arguments are clearer when the follow the form X and Y -> Z rather than Z because X and Y.

• Question: What is the form of argument used in the 24.65 paragraph?
• Answer: "X has the effect that Y, because Z, and [Y also implies] Q."
• Question: What is the form of argument used in the tbj paragraph?:
• Answer: Z and may be unable [implied therefore] Q. X and Z has the effect Y.
• Conclusion: The second version is according to the lemma.

This post is really long, but I felt it was necessary to explain my reasoning completely and expose what I had previously tried to imply. Tbjablin 03:13, 17 April 2007 (UTC)

-- reply --

First off, get help. Second, I understand what you're saying, but someone stating a fact that you don't like or that you find to be "negative" isn't inherently POV, and you have no real reason to move what you see as something nice to the front of the sentence to suit your preference of what is a "positive" or "negative" thing to say. That would actually be completely POV, and it certainly isn't a quality improvement. However, if we're going to go with your idea of what is a positive or a negative fact, and with your assertion that the paragraph should cover all of one and then all of the other, then stating the "problem" would seem to be a logical beginning for the paragraph, because in this case the "positives" are extending and mitigating a primary about unavailability. So to hopefully resolve this, I'll restructure the sentence according to the points you've made, and hopefully we can both agree that the basis of your concern has been resolved. 24.65.79.192 05:43, 17 April 2007 (UTC)

-- end of reply --

The previous version was better. I didn't like the previous version particularly, but the last sentence of the new version has major stylist problems in that it combines what I think are two unrelated ideas. Also, I think you are taking this whole thing too personally to listen to me. Maybe when Hervegirod shows up again he will be able to persuade you. Tbjablin 10:10, 17 April 2007 (UTC)

Hervegirod definitely shares your desire to see Java presented in as positive a light as possible, but unlike you, he tries to do that by contributing facts and information, rather than removing facts and disrupting the logical sequence of any factual assertion that isn't pro-Java. 24.65.79.192 17:04, 17 April 2007 (UTC)

The truth is I have a feeling that the situation for .NET and Java platforms is very similar, in many ways: a non-free "reference implementation" (for now, even for Java, I agree), and several free implementations (with one of them ahead of the others, Mono for .NET, and Classpath for Java), trying to catch-up, but lagging a little from the reference. Also a situation about the status of the specification and freedom to implement / to participate to the spec that is not always clear (for example, the patents and the parts of .NET that is not standardized, the JSR rules for Java and the status of Sun, for example). I think that many facts are backing this (simplistic, I agree) conviction, but I also agree that this is only a conviction, without value if not backed by facts. Hervegirod 00:35, 19 April 2007 (UTC)

And sorry, I just went home late, didn't have time to write more, more on that later... Hervegirod 00:44, 19 April 2007 (UTC)

I think you're basically right. Both .NET and Java are largely driven by proprietary vendors, both have only partial free software implementations, both present legal and technical challenges to anyone who wants to clone the proprietary software. There are a few caveats, though. Microsoft isn't posing as embracing free software, while Sun is at best simply moving to ensure that their product remains the de-facto "standard" everywhere Java is used, and at worst is not even attempting to live up to their free software supporting facade. Microsoft's use of their Windows and IE market shares (over 90% of desktops and 50% of servers AFAIK) to support .NET and destroy Java (and support or destroy many other things) is having a big impact on the market and community. Once upon a time evangelists angrily denied IE market penetration figures, and then the truth finally set in. I think the Java community may be in the angry denial phase in a nearly identical scenario, here, but time will tell. Also, .NET is partially standardized by third parties, the .NET runtime's end user license isn't as scary (IMHO) as Sun's, the .NET development tools barely come with anything but a disclaimer, and the references don't require an agreement. 24.65.79.192 01:35, 19 April 2007 (UTC)

I think that you are a bit hard on Sun when you say that Sun is not even attempting to live up to their free software supporting facade. They already have open-sourced (under GPL) their compiler and their VM, and one could not say that this is nothing (especially considering that HotSpot is maybe one of the fastest Java VMs available). I agree that they did not open-sourced the Classlib in March like they said, but I think they would want to make a big announcement of it, and JavaOne in May would be the perfect timing for them... Hervegirod 21:35, 19 April 2007 (UTC)

Well, I was saying that may be a worst case scenario, but the truth could be that they are making an effort. I'm just saying at best they're making an effort that is motivated by trying to avoid losing free software market share to Classpath. Personally I have doubts about whether I'll be able to have a free-software-only machine that's 100% compatible with binary Sun JRE in a year, or even 5 years, and that really drives me nuts given that Sun pretends to be embracing Linux, but who knows. All I can really say for certain is that time will tell. 24.65.79.192 23:02, 19 April 2007 (UTC)

However, Sun has announced that it intends to release a Java runtime environment under a modified version of the GPL by March 2007 (a time that has already passed), and has already released two fundamental parts of the JRE and JDK: HotSpot and the javac compiler under the GPL.

Request for Comment: Supporting material in C Sharp and Java article

This article deals with the differences between the programming languages Java and C#. Both languages are heavily associated with supporting platforms (the JRE and .NET Framework.) Regrettably both platforms are also subject to politics, between their users and the industry at large. As the article grew it gathered small sections on issues and topics surrounding the languages themselves. Sometimes it is hard to make a clean break between a language and its supporting software libraries, frameworks and tools. Eventually material was added which touched upon some raw areas of hot debate, and this may well be when the problems began.

There appeared to be some dispute over what was fact and what was POV, with claim and counterclaim that the article was unbalanced. A flurry of edits and reverts over a short period of time resulted. Eventually, after discussion on the talk pages, the article was broken into two. The original article would carry language specific details. The new article would deal with the associated platforms. Unfortunately the split did not end the dispute, as the issue of what belonged where came to the fore, and the issue of what was fact and what was POV (balance) remained unsolved (albeit in a new home.)

As this is the originating article, and much of the original debate, is contained upon its talk page, the RFC has been posted here (the original 'language' article.) The new 'platform' article is Comparison of the Java and .Net platforms.

These talk discussions are the ones which appear to relate to this recent issue, listed as best possible in chronological order:

• Tbjablin's edits
• Runtime inclusion
• Runtime inclusion in operating systems
• Split this article into two: "Java vs C#" and "JRE vs Mono"
• Split this article into two: A SOLUTION
• New article

21:23, 20 April 2007 (UTC)

It seems the threat of RFC, along with Tbjablin's 3RR discussion with 24.65.79.192, has halted the reverts for now, and productive edting has resumed on both articles. As such, I've struck the RFC in the hope that differences can be resolved through pragmatic editing and discussion rather than reverts from this point on. Thank you to all who cooperated in bringing this problem to a speedly resolution. JavaKid 20:47, 21 April 2007 (UTC)

Suspected sockpuppeting

I've noticed an anomaly in the talk page for the user Tbjablin. During this dispute, both Tbjablin and JavaKid have seemed to have the same agenda, and to have taken it up at about the same time, which I found to be a strange coincidence, particularly given that their tactics and general styles have been very similar. They deny that one is a sock-puppet of the other, but I noticed that on Tbjablin's talk page, under the section "Java / C# / Kermit the Frog," there's a note that seems to have been written to look like it was by Tbjablin, but it's signed by JavaKid, and then there's a response that's also signed by JavaKid. The only explanation coming to mind is that the two are in fact sock puppets for a single user, and that the user made a mistake in managing logins, cookies, or something, but I could be wrong. Maybe they were just responding to themselves, but I think it may warrant some investigation. 24.65.79.192 22:06, 20 April 2007 (UTC)

First of all, please assume good faith. Let's consider for the moment that maybe, just maybe, they are not sockpuppeting. How could you explain that second post was signed by JavaKid? I think you know the answer to that one, but I'll give it a try for you. The second post was not a response. Just a second post. Anyway, if you still can't wrap your mind around it, or are just really convinced that there may be faul play here, you could try to make a case at Wikipedia:Suspected sock puppets. – Chip Zero 23:04, 20 April 2007 (UTC)

That's a possibility, too, though JavaKid hasn't changed indent in the numerous other cases where they posted multiple paragraphs. Also, I already had some pretty strong suspicions, because there were so many commonalities between the two users' edits, but I do understand what you're saying. I think there's no need to be hostile here, and you seem a little hostile. If I'm mistaken then I'm mistaken. Either way, like I said, rather than assuming, I'd rather someone with access to logs just checked it out. JavaKid says that they're trying to have an administrator look at this page, so that's why I added the mention there. My complaint would relate to the edit history in this dispute, too, so that's another reason. 24.65.79.192 23:24, 20 April 2007 (UTC)

Even though JavaKid and I are not the same user, I have some sympathy for your dilemma. The reason that JavaKid's comments seem out of context is that they are in reply to things I was saying on his talk page. Basically, I started a conversation on his talk, then he replied on my talk, then I replied on his talk, then he replied on my talk. Here is the link to check user Wikipedia:Requests for checkuser, I think you should use code E or code C, with code E having a higher probability of success. You just need to find a bunch of reverts by JavaKid and I in 24 hours, I think it will not be too hard. Alternatively, you can bring the case up for arbitration, and then request a checkuser from there. I have Comparison of C Sharp and Java in my watchlist, as presumably does JavaKid, that explains why we jumped on the article at about the same time. Beyond a checkuser, I offer the following reasons why JavaKid and I are not the same person:

• Differing sleep schedules: JavaKid stops editing earlier than I do
• Edit style: JavaKid tends to make one sweeping edit and rarely makes mistakes, I tend to make many small edits and frequently fix my own grammer/spelling/formatting/mistakes
• Personality: JavaKid tends to remain cooler during discussions and stays on topic, I tend to respond to whatever points are brought up
• Topics of interest: [15] vs. [16].
• Textual signatures: JavaKid uses emoticons frequently in his talk space edits, I never use them.

I strongly encourage you to continue your investigation. I think it will be impossible for you to assume good faith from JavaKid and I while you suspect that one of us is a sock. On an unrelated note, why is JavaKid always the real person and I am always the sock? JavaKid's first edit is 16:52, January 4, 2006, whereas mine is 17:23, April 14, 2004 , I also have twice as many edits as he does.

Tbjablin 23:25, 21 April 2007 (UTC)

When Tbjablin left his original message on my talk page I wasn't sure if he would be watching it for replies, which is why I responded on his talk page. When his reply indicated he was watching my talk page, I restricted further discussion to that page. Later, when I wanted to send Tbjablin a thank you message for tidying up my C#->.NET edit, it seemed more appropriate to append it to his page than mine. Almost as a reflex action I indented it, although admittedly this leads to ambiguity as it looks as if one is following up from the other (which, very indirectly, it is I suppose...) If you really want further proof then I encourage you to usercheck -- I have nothing to hide, and it would help clear the air. JavaKid 11:00, 23 April 2007 (UTC)

Methods

As for the Methods chapter, I think this part is way too extended and inexact: In Java there is no way to make methods non-virtual (although they can be "sealed" by using the final modifier to disallow overriding). This means that there is no way to let derived classes define a new, unrelated method with the same name.. This is not exact. The only difference is that in C#, methods are non virtual by default, and you have to explicitly tag them as virtual in the base class to allow them to be overridden, whereas in Java they are virtual by default and you have to explicitly declare them as final to disallow them to be overridden.

The other difference is exactly in what that sentence says. In C#, if the method in the base class is non-virtual, you can define the method with the same name in a derived class, and it will not override the original method (obviously, since one can't override a non-virtual method). But also, you can avoid overriding virtual methods by using the new keyword. There is no way to do it in Java. -- int19h 18:22, 13 May 2007 (UTC)

Also: In Java, this will mean that the method in the derived class will implicitly override the method in the base class, even though that was not the intent of the designers of either class: no, because you have to declare super.<base class method> to derive the base class, there is nothing implicit in that. Contrary to methods, constructors are always overridden, implicitly or not, and C# and Java have the same behavior in that way. Hervegirod 10:20, 12 May 2007 (UTC)

The syntax you refer to, super.base-class-name, is for calling the overriden method of the base class from your override; however, it doesn't matter if you do it in the body of your method or not - you will still end up overriding the method of the base class. You can check this out for yourself:

• Create a file called "Base.java" with the following content, and compile it:

class Base { }

• Create a file called "Derived.java" with the following content, and compile it:

class Derived extends Base {
  void foo() { System.out.println("Derived.foo"); }
}

• Modify the file "Base.java" as follows, and recompile it:

class Base { 
  void foo() { System.out.println("Base.foo"); }
}

• A final touch, a file called "Test.java" to see what happens:

public class Test {
  public static void main(String[] args) {
    Base base = new Derived();
    base.foo();
  }
}

And sure enough, you'll see "Derived.foo", which is what got called. However, note that when we compiled class Derived, its base class did not even have the method called foo! We certainly didn't intend to override any such when we wrote it, yet we ended up doing it anyway, when the base class was changed. Now imagine all the above steps being done by different people at different times, and you'll see the problem. -- int19h 18:22, 13 May 2007 (UTC)

OK, but I don't see the problem here. After all, base is an instance of Derived. Also, that put us back to the first discussion about virtual methods (C#) vs final methods (Java). It is a difference between the two languages, but being obliged to declare as virtual methods that intend to be overridden is not always seen as an advantage (see for example the goals of D here. Digital Mars choose to get rid of non virtual member functions for example, saying: In C++, a class designer decides in advance if a function is to be virtual or not. Forgetting to retrofit the base class member function to be virtual when the function gets overridden is a common (and very hard to find) coding error. Making all member functions virtual, and letting the compiler decide if there are no overrides and hence can be converted to non-virtual, is much more reliable. It is the same in Python (there's even no final in Python) and Ruby, and I think even in [PHP]] Hervegirod 20:20, 13 May 2007 (UTC)

The problem with "virtual by default" approach is truly a problem when the class calls its own methods. Imagine, in the example above, if class Base called its own foo to do something useful. If it is silently overriden by Derived, the behaviour can change in many different ways, none of them desired.

I know about that design goal of D, and it seems to be lifted directly from Java. Of course, the criticism as worded does not really apply to C#, since there's no way to forget to "retrofit the base class member function to be virtual" - since you have to explicitly mark overrides with override keyword, the compiler will detect an attempt to override a non-virtual function, and complain. On the other hand, C# gives the benefit of having to explicitly declare the intention (of providing a hook for derived class to override) by requiring virtual, which is a Good Thing, since not any method of any class can be safely overriden - usually not when it's called by the class itself. See this interview with Anders Hejlsberg for a more detailed explanation of this design decision. -- int19h 03:48, 14 May 2007 (UTC)

Unsigned Types

"Java lacks unsigned types." - This is totally untrue, java supports unsigned types with the help of the "unsigned" keyword - can someone please do some proper research and fix this. This statement is very misleading. —Preceding unsigned comment added by 124.197.31.240 (talk) 20:26, 12 November 2007 (UTC)

"Preceding unsigned comment...": ho ho! Anyway, just in case you were being serious, and not just trying to goad the SineBot into unintentional humour, Java doesn't have an unsigned keyword. Only char is considered an unsigned type. JavaKid (talk) 16:14, 19 November 2007 (UTC)

Needs to be updated to reflect changes in c# 3.0

Latest version of C# added a LOT of important features, most of them are side-effects due to the inclusion of LINQ, but still, now c# supports much better the functional programming paradigm as well. —Preceding unsigned comment added by 24.80.96.84 (talk) 04:47, 5 January 2008 (UTC)

Exception handling

This scenario is not possible in java: 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 Any implementation cannot throw a new checked exception, unless it is a subclass of exceptions declared on abstract class / interface / super.method. This constraint is checked at compilation time. Of course it can throw new RuntimeException children classes. —Preceding unsigned comment added by 138.132.54.107 (talk) 14:56, 14 April 2008 (UTC)

That is in fact the problem: if a new implemention introduces a new, previously unanticipated error condition, you can only throw one of the exceptions declared in the interface. – Chip Zero 16:39, 14 April 2008 (UTC)

Ah ok, I see that point now; but don't think it is a limit: all existing interface implementations are guaranteed to continue working, when catching the declared checked exceptions. In c#, the calling methods could be broken by a whatever new interface implementation, unless wrapping the code in a generic catch(Exception e). This is also true for java's RuntimeExceptions. —Preceding unsigned comment added by 138.132.54.107 (talk) 09:59, 15 April 2008 (UTC)

One fun thing about Java is that exception checking is done entirely at compile time. If your .class files get out of sync, you may actually get a checked exception at runtime where there shouldn't have been one. To verify, try this:

1. Create file Foo.java with this content and compile it using javac:

public class Foo {
  public static void blah() { // guaranteed not to throw
  }
}

2. Create file Bar.java with this content and compile it using javac:

public class Bar {
  public static void main(String[] args) {
    Foo.blah(); // guaranteed not to throw
  }
} 

3. Modify Foo.java as follows and recompile it (but not Bar.java):

public class Foo {
  public static void blah() throws java.io.IOException { // throws a checked exception now!
    throw new java.io.IOException();
  }
}

4. Run "java Bar" and observe the unhandled exception stack trace...

-- int19h (talk) 21:00, 16 April 2008 (UTC)

The exception is reported, of course;

       java Bar
       Exception in thread "main" java.io.IOException
         at Foo.blah(Foo.java:3)
         at Bar.main(Bar.java:3)

In my opinion this is strictly related to a missing point in the article; see the section "binary version handling". —Preceding unsigned comment added by 138.132.54.107 (talk • contribs) 11:38, 17 April 2008

Indeed, checked exceptions don't really mix well with different versions of classes. At the source level, if you add a new checked exception specification, all existing clients fail to compile. But then if you update a client, adding a new catch block, it will no longer compile against the older version of the library (as you can't catch undeclared checked exceptions)... So it's really a good thing that exceptions at least aren't checked at load-time :) – Chip Zero 18:20, 17 April 2008 (UTC)

I thought checked exceptions were great when I started programming in Java. Over a long period of time I learned that they were teaching people the wrong lesson about how to use exceptions -- it becomes a matter of suppressing compiler error messages rather than handling errors completely. I don't accept the idea that it's a 'break of contract' for some strange exception to happen inside a method. In a world where plugs are pulled out of the wall and kill -9 signals get sent, methods can't even promise to return. —Preceding unsigned comment added by 74.32.113.151 (talk) 19:29, 27 June 2008 (UTC)

As a note, changing the throws list for a method is considered an incompatible API change. Second, it is possible to have a checked exception thrown even when everything is compiled together either by using Class.newInstance() where the class's no args constructor throws a checked exception (this is done this way for legacy reasons), or by having a generic type parameter throws list and casting a checked exception to that (this causes a compiler warning).Subanark (talk) —Preceding undated comment was added at 07:27, 13 August 2008 (UTC)

Binary version handling

I think it is at least worthy to mention the intrinsic version of binary units in .NET (assemblies) vs plain java's zipped classes container JARs. Really being a .NET vs JVM comparison, I think it should be outlined here too. In c# you can join your release with a versioned dependency.

Event handling

I think part of the paragraph (which is not sourced) is POV:

• anonymous inner classes are not syntactic sugar, which is additions to the syntax of a computer language that do not affect its functionality. anonymous inner classes are not only a syntax addition, they are really different from other Java constructs.
• C# provides extensive support for event-driven programming at language level: clearly POV - and the end of the sentence Delegates support covariance and contravariance, and can be created as anonymous methods with full-featured closure semantics. is more marketing than anything else IMHO. Hervegirod (talk) 23:04, 27 March 2008 (UTC)

Hi Herve. Anonymous classes avoid having to write complete new classes and some parameter passing by hand. Still, the JVM has no direct notion of anonymous classes, the compiler simply transforms them to regular classes for you. Therefore, they can be considered a form of syntactic sugar. I agree that it shouldn't say that C# provides "extensive support" for event-driven programming, that's simply a subjective statement. The other sentence you quote seems to sum up a number of technical terms in rapid succession, and should be to be rewritten and extended with examples. But other than that, the paragraph seems perfectly NPOV. – Chip Zero 15:07, 3 April 2008 (UTC)

Hello, I agree with you, I will try to propose something soon. As for the "Delegates support...", I think it will need a lot of rewriting to make it clear. Maybe it should be broken in more specific sentences. Hervegirod (talk) 09:37, 5 April 2008 (UTC)

Hello, sorry to intervine, but I think that how anonymous classes are implemented by the JVM shouldn't matter (it should be transparent to the language user). The fact is that java provides a special syntax for the definition of classes "without names" that affects the semantic of the language (or do you still think about anonymous classes as regular classes of the package?). Therefore java anonymous classes should't be consider a "syntax sugar", because it changes semantics, wheather the JVM implements it one way or the other. --190.49.246.182 (talk) 00:38, 8 April 2008 (UTC)

Hello again, I rewrote parts of the Event handling and Closures paragraphs, because they overlapped each other. Plus the Event handling part was a bit POV IMHO. I think that we should add a source about the "syntactic sugar" rather than stating it like that, because it is more a matter of taste as it is. We could for example write: "some has said that anonymous classes are more verbose than their C# counterpart, and are more verbose" etc..., rather than writing it ourselves without sourcing it. I will look for sources about that as soon as I have the time - need to go to eat now ;-) Hervegirod (talk) 19:01, 19 October 2008 (UTC)

Namespaces and source files - disputing neutrality, mark as Advert

I am marking this section as advert; it is biased towards C#, ignoring some of its shortcomings and failing to point out the advantages of Java; my claims are based on my findings in VisualStudio 2005, which is what our company currently develops in.

I would like to see at least some of this added to the main page. I have not yet done so myself because I know this is too wordy, so I want to sleep on this for a few days.

The biases:

In the first paragraph, the second and third sentences state that unlike Java, in C#:

   "a namespace is not in any way tied to location of the source file. While it's not strictly 
   necessary for a Java source file location to mirror its package directory structure, it 
   is the conventional organisation."

My issue is that the statement does not explain any of the many benefits or reasons for the "conventional organization" in Java, nor go into details that C# does not really support that structuring (and not that organization is the correct spelling :-D). I'll expand in a second with examples.

The second paragraph starts with:

   "Both languages allow importing of classes (e.g., import java.util.* in Java), allowing 
   a class to be referenced using only its name."

This statement is, at a minimum, vague. The part I have a problem with is that it seems to imply that in both languages, you can simply add the import/using statement then have access to the class, which is not the case at all.

My arguments / examples to support my claims:

In regards to C#, the second statement ignores the fact that if the features you are wanting to import exist in a different "project" or dll, you must first add a reference to the project/dll you wish to use in your current project, and that IS NOT done by simply saying "using". Basically, in C# / VS, projects are boundaries of sorts, and anything that falls outside of that project must be added as a reference to your project. For example,

   the project MathUtils has a class MySillyMath in the namespace/package yourname.legos.mathutils
   the project SomeApp wants to use MySillyMath in the class ImUsingSillyMath,
   the project SomeApp must:
      1. add a reference in the project SomeApp to the project MathUtils
      2. add the "using" clause to your class ImUsingSillyMath

Since that's only one additional step for C# versus Java, that may seem trivial, but it is not.

The recommended method for adding a reference to another project (MathUtils, in my example) is to include the needed project in your solution, that way it is compiled with your target project. (I will add citations backing this statement later today.) Your alternative to that is to add the reference to compiled binaries (which would be mathutils.dll in my example) however again, the recommendation is again to add the project as source code if available.

So exploring the idea of adding the source project to your solution, we run into some more difficulties.

If you try to make your folder structure follow the namespaces, and assuming that the ImUsingSillyMath is in the namespace of yourname.apps.someapp, you have (whether C# or Java):

 /programmingdirectory
   -/yourname
     --/apps
       ---/someapp
     --/legos
       ---/mathutils

For Java, since you have structured your directory the same as you have your packages, you simply set the classpath at compile to "/programmingdirectory"; you then add your import statement in someapp to:

   import yourname.legos.mathutils.*;

So with Java, two huge benefits of arranging your source code in the same way as your packages/namespaces are:

 1. you know that the package yourname.legos.mathutils can be found at .../yourname/legos/mathutils; 
    very handy if you're looking for code other than yours.
 2. when compiling /yourname/apps/someapp, which states "import yourname.legos.mathutils;" and has a 
    classpath set to .../programmingdirectory, your source code at mathutils will be compiled

For C#, it's if you create SomeAppSolution.sln in the apps/someapp folder, and you have not copied the /legos/mathutils folder (either by copying it there through Windows Explorer, or, assuming you're using a repository that supports externals, i.e Subversion), then the solution/IDE copies the source folder into your solution's folder! That means that your original code, which you had in .../yourname/legos/mathutils IS COPIED to .../yourname/apps/someapp/mathutils! The side effect of this should be obvious. You now have:

 /programmingdirectory
   -/yourname
     --/apps
       ---/someapp
         --/mathutils
     --/legos
       ---/mathutils

Finally, the summary!

Comparing the strengths of packages in Java over the namespaces in C#:

   1. Folder organization
       a. In Java, by organizing your folders the same as your packages, 
          you know where to find source code by simply looking at the import statement. 
       b. In C# solutions require that the source code be in a subfolder to your solution; 
          this breaks the mimicking of the folder structures to the package/namespace structure, 
          and can end up creating duplicate code.
   2. Source Code compiling:
       a. In Java, by organizing your folders the same as your packages, your import statement imports the code 
          AND tells the compiler where to find the source code for compiling; this is a one step process.
       b. In C#, if the code/namespace you wish to use is in a different Project, it is a two-step process at a minimum. 
         1. You must first add a reference in your project to tell it where to find the source or binaries for 
            the project you wish to use BEFORE the using statement will compile;
         2. You may then add the using statement
         Note: if you wish to add a reference to the source code (instead of the binaries) you must first 
            (before 2.b.1) add that project to your solution. Not only is this a third step, but unless using 
            a repository that supports externals, this WILL create a duplicate copy of the source code under 
            your solution, thus breaking the folder structure mimicking the package/namespace structure, AND 
            results is duplicate code; the original code is not used by your solution, rather a copy of it 
            from that point in time is!
         

If anyone wants screenshots backing my claims, needs additional links or references, or has questions or suggestions on how to clean this up, I'm all ears. Alreadyused (talk) 18:04, 21 May 2008 (UTC)

First, we should be note that you are mixing IDE (Visual Studio) features and requirements with language features. Sticking to language features, I hope I summarize accurately in saying that in C#, the language is independent of any file system references. IDE access to related source code and binaries is accomplished by mappings contained in a project file. Compiler access to the same is accomplished through options specified at compile time. In Java, the import statement introduces a relationship of source code to the file system. As you point out, this can be seen as an advantage (the developer can look at the import statement to determine where the code resides) but could also be a disadvantage, as moving source code can break referrring source code. I wouldn't argue that either of these is obviously better.

Second, it simply isn't the case that VS 2005 "solutions require that the source code be in a subfolder to your solution ". I have a counter-example at hand, I'll just post the bit of the .sln file that references the two projects in the solution:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ConsoleApplication1", "ConsoleApplication1\ConsoleApplication1.csproj", "{B0F288CC-C6A8-4038-840F-E444AE66B62F}"

EndProject

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Utility", "K:\user\lit\Utility\Utility.csproj", "{7B792D15-BFAE-44F7-AAD5-F1C74102EA54}"

EndProject

The first project, "ConsoleApplication1", is located below the folder of the .sln file, while the second project is located on another drive. I don't know why you are seeing a copy of the source to the sln folder. Perhaps it involves a configuration option you have chosen, or perhaps your source control system requires it.

Leotohill (talk) 04:36, 20 July 2008 (UTC)

Your claims appear to be about IDEs and not about the languages. I have deleted the POV as it was based on a misunderstanding about the focus of the article.Useerup (talk) 13:47, 22 November 2008 (UTC)

Attributes vs Annotations

A entry should be added on Java's Annotations vs C#'s attributes. They have much in common, but have quite a few differences. Consider tossing in JSR 308 in there too. —Preceding unsigned comment added by Subanark (talk • contribs) 07:30, 13 August 2008 (UTC)

Generics

I removed part of the 'following sentence: Java's approach requires additional run time type checks, it does not guarantee that generic contract will be followed, and lacks reflection on the generic types.. After the partial removal, the sentence was: Java's approach lacks reflection on the generic types..

However my removal was rv, and as I understand why it was done, I still have concerns with the sentence: It implies (falsely) that programmers who use generics have to add additional run time type checks in their code, because the generic contract may not be followed. In fact, I think who added the sentence thought about the Java compiler itself, which adds runtime casts. Only the lack of reflection is "visible" to the programmer.Hervegirod (talk) 20:05, 27 September 2008 (UTC)

Hi Herve, looking at the text again, it seems the points this sentence tries to make are mostly stated in the paragraphs that precede it. The contract thing is also a bit exaggerated, so I'll just remove it again. – Chip Zero 18:28, 30 September 2008 (UTC)

Numeric applications

There is a problem in this paragraph. It is said that Java has a support for BigDecimal, and that it lack the capability to provide the same level of integration for these types than with primitive types, whereas C# provide operator overloading, etc... We don't compare the same thing here, we should put the part dealing with the level of integration for type elsewhere. Plus the next paragraph also deals with operator overloading !!! All in all, a lot of sentences are to be found more than once in this huge article. There's still a LOT of work to make it a good article ;-) Hervegirod (talk) 19:12, 19 October 2008 (UTC)

Event handling

I'm sorry but I had to delete this misleading sentence: On the other hand, Java does not have special types defined for event handling. Instead, events signatures are defined in interfaces. Classes that wish to be notified of a event implement the interface, and register themselves with the event producer. Because there is no language-level construct for event handling in Java, conventions are used instead. For instance, interfaces that are related to event typically end with the word Listener, while event parameter are suffixed with Event. Method used to register or unregister with an event producer typically are called add + the name of the event interface. Saying that there is no language-level construct in Java for event-handling is false. And if you want to say that there is nothing comparable to delegates, delegates are not used only for events, so we could also say that there is no language-level construct for event handling in .NET as well ;-) Feel free to re-add parts of the original text in the paragraph (maybe you think that I deleted too much), but I still think that this whole sentence was misleading and additionally was very difficult to understand. As for the example, it is a comparison article, if you want to explain things about events in Java, do it in the appropriate Java language article. Hervegirod ([[User talk:Hervegirod|talk]]) 23:30, 12 November 2008 (UTC)

I'm wondering why you are disagreeing with the above statement. I don't disagree with the fact that the entry may have been long and poorly worded, but since it's a comparison article, I thought it would be important to reflect how events are handled in Java. The original entry makes it sound like the only way to implement events (or delegates) in Java is via anonymous inner class. --Jfbilodeau (talk) 15:27, 13 November 2008 (UTC)

Actually, I think I see what's wrong: 'Java does not have special types defined for event handling.' The sentence should have read 'there is no language-level construct for event handling in Java.'. What is the entry was reworded as follows: "On the other hand, there is no language-level construct for event handling in Java.' A brief description of the event producer--listener could be included. As for C#, a delegate is a language-level construct. I agree that delegates are used beyond event handling. Maybe we should label the section 'Event handling and callbacks.' --Jfbilodeau (talk) 16:24, 13 November 2008 (UTC)

Yes, as delegates is not an event-only mechanism, saying that C# has a language-level construct for event handling is still not exactly true. So I agree with your proposal to rel-label the section. We could then begin the paragraph by saying that C# has a language-level construct called Delegates to handle events and callbacks. Then you can write than Java has no such language-level construct, but provides anonymous classes, etc... and then you could end by saying that anonymous classes are seen by some as syntactic sugar, etc... Hervegirod (talk) 22:17, 13 November 2008 (UTC)

I did a lot of minor changes to the event handling method. Probably the most important change is the name of the section, which is now called 'Callbacks and Event Handling.' I've taken the liberty of indicating that delegates and closures is C# are syntactic sugar, just like anonymous inner classes in Java. It didn't feel like a fair criticism of Java otherwise. I hope the changes are agreeable to everyone! Jfbilodeau (talk) 21:55, 17 November 2008 (UTC)

Javadoc

There doesn't seem to be a section on Javadoc and the equivalent in .NET. Should this be added? Jfbilodeau (talk) 22:07, 17 November 2008 (UTC)

Language history and evolution > Java

Even as someone who considers himself a hardcore Java nerd for years, I find the section "Language history and evolution > Java" very distasteful; it gave me the impression that the pro-Java editors were too desperate, and the too often jabs (which reeks of bitterness to me) to the "competing" language C# certainly did not help to alleviate this backfiring biased style of writing.

Unless of course it was written by the C# crowd, then congratulations, I guess your plan has worked. 125.60.241.168 (talk) 07:47, 22 December 2008 (UTC)