Talk:Comparison of C Sharp and Java: Difference between revisions

Revision as of 16:02, 30 July 2011

Latest revision as of 17:10, 30 July 2025

(180 intermediate revisions by 59 users not shown)

Line 1:

{{WikiProject Java|importance=low|class=start}}

{{User:MiszaBot/config

|archiveheader = {{aan}}

Line 8 ⟶ 7:

|archive = Talk:Comparison of C Sharp and Java/Archive %(counter)d

}}

{{WikiProject banner shell|class=List|

{{User:WildBot/m04|sect={{User:WildBot/m03|1|Comparison of Java and C Sharp#Arbitrary size numbers|below|#Arbitrary size numbers}}, {{User:WildBot/m03|1|Comparison of Java and C Sharp#Enumerated types|Enumerated types|#Enumerated types}}, {{User:WildBot/m03|1|Comparison of Java and C Sharp#Event handling|event handling|#Event handling}}, {{User:WildBot/m03|1|Comparison of Java and C Sharp#Functional programming|Functional programming|#Functional programming}}, {{User:WildBot/m03|1|Comparison of Java and C Sharp#Nullable types|Lifted (nullable) types|#Nullable types}}, {{User:WildBot/m03|1|Comparison of Java and C Sharp#Runtime binding|Runtime (dynamic) binding|#Runtime binding}}, {{User:WildBot/m03|1|Comparison of Java and C Sharp#Runtime type information and -manipulation|Runtime type information and -manipulation|#Runtime type information and -manipulation}}, {{User:WildBot/m03|1|Comparison of Java and C Sharp#Tuples|Tuple|#Tuples}}|m04}}

{{WikiProject Java |importance=low}}

{{User:WildBot/m01|dabs={{User:WildBot/m03|1|CLR}}, {{User:WildBot/m03|1|generics}}|m01}}

{{WikiProject Computing |auto=}}

{{Archive box |search=yes |bot=MiszaBot I |age=3 |units=months |

}}

* [[Talk:Comparison of Java and C Sharp/Archive 1|Archive 1]] <small>(2005–2008)</small>

{{Archives |bot=Lowercase sigmabot III |age=3 |units=months }}

* [[/Archive 2|Archive 2]] <small>(2009– )</small>

{{Broken anchors|links=

* <nowiki>[[Arbitrary-precision arithmetic#Arbitrary-precision software|software for arbitrary-precision arithmetic]]</nowiki> The anchor (#Arbitrary-precision software) [[Special:Diff/633704642|has been deleted]]. <!-- {"title":"Arbitrary-precision software","appear":{"revid":33896264,"parentid":33891953,"timestamp":"2006-01-04T22:34:11Z","removed_section_titles":["Uses","Software examples"],"added_section_titles":["Applications","Algorithms","Arbitrary-precision software"]},"disappear":{"revid":633704642,"parentid":632305701,"timestamp":"2014-11-13T19:24:31Z","removed_section_titles":["Arbitrary-precision software","Libraries","Stand-alone application software","Languages"],"added_section_titles":["Software libraries"]}} -->

}}

__TOC__

== Platform support ==

This section is obviously misleading. Mono does not support all the features that we have added in c# column (e.g. functional programming). This table actually says us that C# is multiplatform language but it is not. <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/77.37.180.86|77.37.180.86]] ([[User talk:77.37.180.86|talk]]) 18:11, 20 June 2011 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

Functional programming is supported by MS C# or Mono C#. Mono supports C# 4 in full (http://www.mono-project.com/Compatibility). Please remember that this is not a framework comparison, but a comparison of two programming langauges. Functional programming refers to lambdas, closures and the fact that functions are 1st class objects in C# 3+, supported on all platforms. [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 21:56, 23 June 2011 (UTC)

I don't believe you can compare C# to Java without including the framework. Because the framework itself supplements what the language does not support. And what is, and is not moved from the language into the framework is of itself a debated topic.

Lambda Expressions, however, are an extension to the C# language. Just like Macro's are an extension to the C++ language. Neither are the language, even if they are mingled together like they are.

[[Special:Contributions/173.167.141.1|173.167.141.1]] ([[User talk:173.167.141.1|talk]]) 18:56, 28 July 2011 (UTC)

Lambda expressions are part of the C# language spec. It is not an extension to the language any more than the for loop is. As for including "the framework" please see the discussion on this very topic elsewhere on this page. It is a difficult nut to crack because you are of course right that ''some'' language features are complemented or replaced by framework features. But what ''parts'' of the framework should then be used as base for the comparison? java.lang? (yes) java.util? (probably yes, some of it), java.awt? (no!). [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 16:02, 30 July 2011 (UTC)

== Value types ==

C# value types are not syntactic sugar. To meet that definition you would have to demonstrate what kind of code is really generated which you could have written yourself. You cannot do that with value types as they exhibit ''copy semantics'' - i.e. they are stack allocated and new copies are created when assigned or passed as parameters. Apart from that, being "syntactic sugar" is not an impeachment. Every single programming language is rife with "syntactic sugar". For loops are syntactic sugar: You can demonstrate how the resulting code can be generated as a result of statements and a while loop (or vice versa). Syntax matters. [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 22:26, 25 October 2010 (UTC)

:Response: Value types are not a language feature,end of story, your wrong , give it up. Nobody outside Redmond and MS Fanboys cares about value types. They are not defined in any computer science literature, they are an invented type by MS. Not once in programming in C/C++/python/ruby/java/ADA/perl have I ever heard someone say 'geez wiz I wish I had value types'. You really need to stop arguing with everyone on this page. You keep reverting peoples changes, pretty much disagreeing with everyone where they are saying there is bias. How are we suppose to get rid of bias if you are allowing any real changes? <small><span class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Bongey|Bongey]] ([[User talk:Bongey|talk]] • [[Special:Contributions/Bongey|contribs]]) 14:46, 26 October 2010 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

::"Value types" is a kind of language feature.<br /><br />In Java, they are called primitives.<br />In C++, the difference can be summed as "Do I own the object directly, or through a (smart of not) pointer?". The difference is very important, as in C++, the last thing you want is to allocate everything through a new, if only because of performance reasons. But I should not have to explain you this, as you claim extensive experience in C++.<br /><br />Anyway, this is exactly the reason why in Java primitives are not objects (I was told they tried having all primitives being true objects at first, but turned back because of performance).<br />In C#, they made Value Types derived from Object, but still made them "primitives" as understood by Java.<br /><br />So Value Types are, as primitives, a language feature.<br /><br />Fact is, Value Types as understood by C# are a first-class citizen of C#, when their equivalent (primitives) are not in Java:<br />C# handles boxing/unboxing when needed, and does not impose boxing/unboxing when it is not needed, for example.<br />Java is unable to handle primitives correctly without always boxing them first (for example, in generics).<br /><br />Thus, the difference in handling Value types/primitives by the two languages is very important, and should be explicit in the current article.<br />[[User:Paercebal|Paercebal]] ([[User talk:Paercebal|talk]]) 13:05, 23 April 2011 (UTC)

::: I fail to see what's specific in Value Types, except Microsoft's marketing maybe. In .NET value types are also boxed / unboxed, because .NET really wraps the primitive values in Objects, and this operation cost a lot, like in Java. Also transparent boxing / unboxing of primitives is also managed in Java, for example this is perfectly valid Java code:

<pre>

List<Integer> list = new ArrayList();

list.add(2);

int value = list.get(0);

</pre>

More than that, if you try to code the same examples provided by Microsoft to explain how Value Types are working, these examples also work in Java, with an almost identical syntax.[[User:Hervegirod|Hervegirod]] ([[User talk:Hervegirod|talk]]) 21:41, 24 June 2011 (UTC)

You are mistaken, value types are not boxed/unboxed in .NET like they are in Java. This would be the code in C#:

<pre>

var list = new List<int>();

list.add(2);

int value = list[0]

</pre>

And it would ''not'' involve the relatively expensive boxing and unboxing conversions. This goes for any primitive and value type (primitive types are just a subset of value types). <code>int</code> is a value type, and in C# you can define new value types. Only when value types are treated ''like objects'' (reference types) are they boxed. You may declare arrays of custom value types and the array will contain the actual values not a boxed references to values. [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 23:23, 26 June 2011 (UTC)

== Is this entire article directly lifted from some page at microsoft.com? ==

Because it looks like it. It reads like an essay and one that seems to be written for Java programmers to switch to C#. [[User:Rajakhr|Rajakhr]] ([[User talk:Rajakhr|talk]]) 09:21, 18 May 2010 (UTC)

:If you compare two things, and one appears better, you can either:<br />- Hide your head in the sand, and claim it's a conspiracy<br />- Add meaningful and truthful arguments that were forgotten<br/>- Accept the apparent better one is the better one.<br />So please, contribute in a meaningful and truthful way, if possible...<br />[[User:Paercebal|Paercebal]] ([[User talk:Paercebal|talk]]) 13:04, 23 April 2011 (UTC)

::Besides, the goal of this comparison is not to determine which language or feature is ''better'', but simply to allow programmers to compare possibilities for expressing things in the two languages. [[User:Rp|Rp]] ([[User talk:Rp|talk]]) 08:03, 7 June 2011 (UTC)

== Setting the ground rules ==

Rather than speculating what motives we each might have for wanting a certain section (green or red?) included or not, I suggest that we set some ground rules here. It is a complicated issue and there are some gray areas, but with a lot of the topics I think we should be able to come to a consensus.

IMO the overall goal should be a comparison between the two languages as they are experienced by new programmers learning just the language and basic library as they are used across all reasonable disciplines.

Both languages were designed alongside their respective VMs. That a language happens to not have a specific ''syntactic'' construct for a given feature, but only a "library" feature does not rule that feature out. Case in point: Java's "soft" references. This is a VM feature which has no specific syntactic representation. It can only be used through a core library. But this feature exists and soft references has semantics different from weak references.

Likewise, some of C# conditional compilation features and assertions - which are clearly language features - do not have specific syntactic constructs. Instead they are used by adorning methods with metadata which is understood by the compiler. While attributes is a language feature, those ''specific'' attributes are defined in a library.

Clearly, we cannot draw the line just at the language specification. Significant features would be left out of both languages. To complicate matters, corresponding concepts are sometimes surfaced with syntax elements while the almost exact same feature (clearly present) in the other language has been factored as library feature giving access to the VM feature. Case in point: Synchronization. This was introduced in Java before annotations, hence synchronization is declaratively set with a language ''keyword''. C# had annotations ("attributes") from the start, and chose to surface the almost exact same feature through concrete metadata attributes. Does that mean that C# does not have declarative synchronization? Clearly not! The underlying synch mechanisms of the VMs are just surfaced through different channels.

Because we clearly need to allow some "core" libraries from both languages we need to set some rules for what is in-scope and what is out of scope. In my opinion this article *should not* deteriorate into a comparison of application servers. That is taking it too far.

My initial suggestion is (feel free to suggest changes):

* VM features are in-scope whether they are surfaced through language keywords or syntax or a *core* library

* C# ''System'' namespace "contains fundamental classes and base classes that define commonly-used value and reference data types, events and event handlers, interfaces, attributes, and processing exceptions" (quote documentation)

* Java's java.lang "Provides classes that are fundamental to the design of the Java programming language" (quote documentation)

* C# 'System.Collections' and 'System.Collections.Generic' because all developers uses collections and you couldn't imagine a modern language without standard collection types

* Java's collections etc. from java.util.* because all developers uses collections and you couldn't imagine a modern language without standard collection types

* C# System.Linq (but not System.''Data''.Linq etc) namespace, because LINQ clearly is a language feature and this is where it is surfaced (this is the LINQ to objects stuff and the general LINQ stuff - nothing remotely comparable to Hibernate, JDO or JPA)

* Java's java.lang.annotations - because this is how annotations (clearly a language feature) are surfaced.

* Java's java.lang.ref - weak and soft references which is basic interaction with the GC

* C#'s System.Reflection and System.Reflection.Emit namespaces - reflection is tightly coupled to both languages

* Java's java.lang.reflect package - reflection is tightly coupled to both languages

In-doubt:

* Java's java.math - big integers and decimals

* Java's java.text

* C#'s System.Collections.Concurrent. With .NET4 and task parallelism this is almost a 1st class concept. but...

* C#'s System.Numerics - big integers and complex numbers <small><span class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]] • [[Special:Contributions/Useerup|contribs]]) 21:23, 10 September 2010 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

=== Response ===

'''Wikipedia is not original research''' I'd like to also take point in the fact that this article seems to be talking about a language called "Java". But this language that the article seems to refer to doesn't exist. Indeed, it's part of the requirement of all Java implementations to include certain functionality in their class library. Making a comparison between Java and C# and not including Java's standard library in the comparison is not really comparing Java and C#.

'''Wikipedia is verifiable''' It seems interesting that you want to include your own subjectivity into articles by randomly including and excluding namespaces as it suits you. But that's not how Wikipedia works. If you really thing System.Linq is part of C# and not .NET, you need verifiable references. It's not Wikipedia's job to invent language features. Or we can just include the standard class libraries of BOTH languages in this article. Which is a more useful comparison. [[User:Jbenjos|Jbenjos]] ([[User talk:Jbenjos|talk]]) 00:21, 12 September 2010 (UTC)

:This article is not research. Every fact should be verifiable by an authoritative source, otherwise it doesn't belong here. Do you find any such issues then fix them or report them here. The language specifications are clearly authoritative sources. If a concept (such as query expressions and expression trees) are mentioned in ''the specification'' as a language feature then ''it certainly belongs here''. Do you have a problem with that? Why would you want to exclude something which are in the language specification?

:Java ''most certainly'' exists as a programming language. I believe you may be confused about the relationship between the language, the virtual machine and the standard class library. This is NOT a comparison of the VMs. This is NOT a comparison of the entire stacks (.NET versus Java SE/EE). There are other articles for that. This is a comparison between programming languages. Now, are there perfect demarcation lines between the VM, the language and the BCLs? No, the lines are murky. I gave several examples of that above.

:I am aware that a very narrow definition (e.g. ''only'' the language specs) could misrepresent one or both of the languages. If a certain feature is part of one of the languages but the designers of the other language opted to put a similar feature into the BCL, then it would not be an accurate representation to say one language has it while the other one doesn't.

:''However'', if you decide that "BCL" means JavaSE) you also include awt, swing etc. These are obviously NOT language features.

:My list above was an attempt at a ''discussion'' here about where to draw the lines. Instead of wild accusations, perhaps you would care to engage in such a discussion? <small><span class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]] • [[Special:Contributions/Useerup|contribs]]) 22:01, 12 September 2010 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

::Can you please point to this class library lacking programming language called "Java"? I'm sure Oracle would like to know about it. You CAN NOT call something Java that doesn't pass the Java certification process - which includes a wide implementation of the class library [[User:Jbenjos|Jbenjos]] ([[User talk:Jbenjos|talk]]) 00:48, 25 September 2010 (UTC)

:::Please explain, do you say that there is no such thing as "the Java programming language" because Oracle will not allow a 3rd party to market anything using the Java trademark unless it implements the full JavaSE? <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/83.94.199.190|83.94.199.190]] ([[User talk:83.94.199.190|talk]]) 17:26, 29 September 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

:::The most '''authoritative source''' for anything Java ''language'' is: '''Java™ Language Specification, Third Edition, The. By: James Gosling; Bill Joy; Guy Steele; Gilad Bracha. Publisher: Prentice Hall. Print ISBN-10: 0-321-24678-0'''. Please point us to where in this specification (this is ''the'' specification) it says anything about: AWT, Collection classes, application servers, ''platforms'', enterprise etc. What you will find is that it says something about strings, classes, generics and type erasure, blocks and statements, expressions and binary compatibility. Why is it so hard to make a comparison of programming languages just about the languages. If you feel that Java (the ecosystem) or JEE has so many advantages that you absolutely *must* declare them to the world, then ''please'' edit the correct article for that. ''This is not the correct article'' for comparing enterprise stacks or platform deployments. This article is about ''programming languages'', you know, like C++, C, Python, LISP etc. [[User:Useerup|Useerup]] ([[User talk:Useerup|talk]]) 15:20, 30 September 2010 (UTC)

'''Response''': I think the comparison should be limited to pure computer science concepts, not invented by either sun or microsoft. if you are purely doing a '''language''' comparison. Many of '''features''' in C#, when opening up my programming languages book are not defined. If there is no '''universal''' definition to programming feature , it '''should be left out''', if you are just doing a language comparison. <small><span class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Bongey|Bongey]] ([[User talk:Bongey|talk]] • [[Special:Contributions/Bongey|contribs]]) 20:46, 25 October 2010 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

::Because neither Sun nor Microsoft has or could contribute to the body of knowledge referred to as "computer science"? <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/76.23.17.34|76.23.17.34]] ([[User talk:76.23.17.34|talk]]) 02:17, 13 February 2011 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

=== Another response - drawing the line ===

There is a wealth of good discussion here, and I hope my humble contribution can advance it. I came here as a long-time C# programmer orienting myself to Java. As such, an article like this is certainly a useful reference (a "keep").

It's pretty obvious that C# is more feature-rich than Java, as a language, for better or for worse. It's hardly biased or even surprising. But note:

* Most of the time, a "feature" in one language is at least something that can be done in the other, or even in C for that matter, in a more roundabout way. But when that's not the case, it is a key point to note.

* Language features are good--if I may say that with neutrality--in that they simplify or streamline something valuable (C# <code>using</code> is a classic example).

* They are bad in that they add complexity to the language itself. If a dozen specialized keywords can be eliminated in favor of one general-purpose solution, the language may be better off. Perhaps the feature-poor Java has a cleaner way of doing something with existing facilities.

The last part, BTW, reminds me of a [http://www.relisoft.com/resource/transfer.html quote] that has stuck with me for years:

:"There is only one small problem--modifying the C++ standard is as easy as running for President of the United States. When I mentioned my idea to Bjarne Stroustrup, he looked at me as if I just asked him to lend me a thousand dollars. Then a sudden idea struck me. I can implement strong pointers myself...."

That said, weighing the respective merits of Java's approach versus C#'s is not our task; '''illuminating the differences''' is. Readers such as myself are less interested in the which-is-better debate and more interested in understanding how constructs in one language translate most succinctly into the other. To that end, a yes/no feature chart is somewhat useful and a good starting point or summary (the yes, yes lines strike me as a bit silly, though). More useful still is an item-by-item comparison of "this is the C# way" versus "this is the Java way".

'''Useerup''', I agree wholeheartedly with your comments above and elsewhere, if not your detailed list.

We can frame our discussion by asking:

# What aspects are really part of the ''language'' (rather than the libraries or VM)?

# What is the most useful and natural topic of comparison--strictly the languages, or also some related issues in the libraries and VM?

The second question is important because, if we find it difficult and not worthwhile to draw the fine line between C# and .NET or between the Java language and Java, we should consider adjusting the topic of the article to something more natural and useful. That said, I prefer ''not'' to be expansive, as comparing all the other stuff is typically far less valuable than comparing fundamental syntax and capabilities.

Now some specifics:

* To the extent that the language depends on a very small part of the class libraries (e.g. C# <code>int</code> implies <code>Int32</code>, <code>ValueType</code>, and <code>Object</code>), all those dependencies are definitely fair game.

* Features of the VM accessed only through libraries, such as the various shades of weak references, are noteworthy but not really part of the language. I imagine that a novel VM (the next Dalvik, say) might handle things differently without violating the language itself.

* Reflection, of course, is of great interest, but consider this: a VB.NET program can use reflection to inspect compiled code written in C#, though it cannot tell that the source was C#. It's a subtle but real distinction. Reflection is really only indirectly related to the languages via the bytecode.

* Collections, fundamentally important as they are, are just libraries. So what if the .NET BCL doesn't include a priority queue class? You can easily add that class from another library, or write it yourself. In the same vein, so what if Java doesn't have complex numbers? (Contrast with generics, which must necessarily be baked in from the start.)

* LINQ is clearly an important language feature. Particular extension methods (e.g. <code>Any</code>), though they blur the line a bit, are library. Not that it matters, with Java lacking all this.

* Boxing is not exactly a syntactic issue, but it is critical for understanding what you are really telling the program to do ('''Paercebal''' talked about this at length elsewhere here). In general, when differences under the hood bleed into the languages, they are worth explaining.

* Again, let me emphasize that library features are worth mentioning by way of contrast or alternative to syntactic features in another language. For example, mentioning C#'s native event-handling features might naturally entail mentioning the <code>EventListener</code> interface on the Java side. I don't want to just see "Java doesn't have this", but rather, briefly, '''what Java does instead'''. (The table of course has too little space for details, but the article text will elaborate.)

I see the language as an "inner circle", a core that I will start with to learn the differences between Java and C#. The next bigger circle can include things like weak references and the collection classes. The most gigantic circles can extend to comparing, at a high level, WPF with Swing or whatever. These are all articles I would like to read, but ideally not all mixed together.

I'd like to trim down the feature table a bit. I'm afraid taking out the "yes, yes" items would leave a big column of "no" for Java and "yes" for C#, exacerbating the apparent bias. (If it came to that, it might be better to just have sections "C# features not in Java" and vice versa.) But it may actually be better to replace "yes" and "no" with, let's say,

* native syntax

* library (no, but...)

* none

Not that I will try myself, being so ignorant and biased.

--[[User:SlothMcCarty|SlothMcCarty]] ([[User talk:SlothMcCarty|talk]]) 05:52, 7 June 2011 (UTC)

I agree with you. The standard way of defining a listener in Java is by using interface EventListener. The standard way of defining a property is by following the JavaBeans specification. etc. And ''it's pretty obvious'' that the reason for which the Java language intentionally lacks some specific syntax for these features, is that they can be easily implemented in the class library instead, so that the language can be kept simple. Therefore, I think it definitely makes little sense to talk about the programming language without saying that, in a real-world application, you will typically make use of some BCL class instead of a language-specific keyword. --[[Special:Contributions/151.75.53.61|151.75.53.61]] ([[User talk:151.75.53.61|talk]]) 03:36, 10 June 2011 (UTC)

== Edit ==

I removed the following content:

"Another criticism of checked exceptions is that a new implementation of a method may cause unanticipated checked exceptions to be thrown., which is a contract-breaking change. This can happen in methods implementing an interface that only declares limited exceptions, or when the underlying implementation of a method changes. To allow for such unanticipated exceptions to be thrown, some programmers simply declare the method can throw any type of exception ("<code>throws Exception</code>"), which defeats the purpose of checked exceptions."

This may not happen with checked exceptions. A checked exception must be declared in the public API of the method (''throws'' clause) if you want to throw it. Therefore you may not throw a new type of checked exception unless you intentionally break the API, and this will not happen neither if you are just implementing an interface, nor change the method implementation (as it is not part of the API). --[[Special:Contributions/151.75.20.202|151.75.20.202]] ([[User talk:151.75.20.202|talk]]) 13:20, 26 May 2011 (UTC)

:You could have added '''un''' instead of removing the whole section. So your reason for removing it must be something else. I'm not sure whether this discussion should be present. Is discussing the ''consequences'' of diffferences between the languages too far beyond the scope of this article? [[User:Rp|Rp]] ([[User talk:Rp|talk]]) 21:27, 27 May 2011 (UTC)

::Actually criticism in the section is specifically about checked exceptions. There is no contract-breaking change if you throw a different unchecked exception, as you are always allowed to throw ''any'' unchecked exception type from within any method, so the section just doesn't make sense if you add ''un''. And, yes, maybe the appropriate place for that is [[Exception handling#Checked exceptions]]. --[[Special:Contributions/151.75.16.218|151.75.16.218]] ([[User talk:151.75.16.218|talk]]) 00:15, 28 May 2011 (UTC)

== Java unsigned integer type "char"? ==

I reverted an edit claiming that the Java <code>char</code> type is an "unsigned 16 bit integer" type. According to the language spec it is an ''integral type'' which as soon as it is used with a numeric operator (such as bitwise shift, -and and -or ) it gets ''promoted'' to an integer. So the <code>char</code> type is not an integer type, neither formally nor practically. It is a separate integral type which is ''convertible'' to integer but is itself not an integer. Please read chapter 5 of the Java Language Specification if in doubt. <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/87.50.3.197|87.50.3.197]] ([[User talk:87.50.3.197|talk]]) 21:23, 12 June 2011 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

== Type system > Enumerations ==

== Modules ==

I am a C# programmer and have been since version 1.0 of the language, but my intimate knowledge of the language may be incomplete. With that said, my understanding of enumerations is that they are type-safe. Also, as far as I know, C# is completely type-safe. It impossible, or near, to do something in C# that is not type-safe.

A section is missing: what are the differences between java's packages and C#'s public/internal visibility keywords on namespace members (which end up correlating with the CLR's modules and assemblies). [[User:Bohan|Bohan]] ([[User talk:Bohan|talk]]) 12:21, 28 July 2018 (UTC)

Enumerations do not derive from integer types (8, 16, 32, or 64-bit), but instead derive from System.Enum which in turn derives from System.ValueType, System.IComparable, System.IFormattable, and System.IConvertible. System.ValueType implicitly derives from System.Object. So, enumerations are value types, but do not derive from any explicit value type. When specifying an integral type for an enumeration, you're merely telling the compiler and runtime what the enumeration's numerical limits are; not deriving from the integral type. The idea of deriving from an integral type is an erroneous one because integral types are value types. Value types are implicitly sealed which means you cannot derive from them.

== Type inference / manifested ==

Enumerations only allow you to assign the enumeration's defined values. Integral values can be assigned to an enumerated type through casting, but this can lead to having values outside the implied range (the defined values) of the enumeration. An exception to this rule is the value of zero, which can be assigned to an enumerated type without casting.

At least C# supports basic type inference support: https://stackoverflow.com/questions/479883/how-good-is-the-c-sharp-type-inference [[User:ShalokShalom|ShalokShalom]] ([[User talk:ShalokShalom|talk]])

It is true that enumerations don't allow anything other than the enumeration values. But, the Enum class defines four ToString methods which will convert any enumeration to a string without the need to define an explicit ToString method on an enumeration. The Enum class also defines several other methods which makes working with any enumeration easy.

== Comparing Stream API and LINQ ==

So in short, I propose that the section on Enumerations be revised. I don't know enough about Java to do it in a non-biased manner. <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Skoobiedu|Skoobiedu]] ([[User talk:Skoobiedu|talk]] • [[Special:Contributions/Skoobiedu|contribs]]) 06:47, 16 July 2011 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

There is a paragraph for LINQ but not for the Java Stream API. Comparing them would be more consistent with the rest of the article. I might add this part in the future but don't have time right now <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/141.79.34.38|141.79.34.38]] ([[User talk:141.79.34.38#top|talk]]) 23:41, 21 January 2024 (UTC)</small> <!--Autosigned by SineBot-->