Editing Comparison of C Sharp and Java (section)

==== Numeric types ====
===== Signed integers =====
Both Java and C# support [[signedness|signed]] integers with bit widths of 8, 16, 32 and 64 bits. They use the same name/aliases for the types, except for the 8-bit integer that is called a {{mono|byte}} in Java and a {{mono|sbyte}} (signed byte) in C#.

===== Unsigned integers =====
C# supports [[signedness|unsigned]] in addition to the [[signedness|signed]] integer types. The unsigned types are {{mono|byte}}, {{mono|ushort}}, {{mono|uint}} and {{mono|ulong}} for 8, 16, 32 and 64 bit widths, respectively. Unsigned arithmetic operating on the types are supported as well. For example, adding two unsigned integers ({{mono|uint}}s) still yields a {{mono|uint}} as a result; not a long or signed integer.

Java does not feature unsigned integer types. In particular, Java lacks a primitive type for an unsigned [[byte]]. Instead, Java's {{mono|byte}} type is [[sign extension|sign extended]], which is a common source of bugs and confusion.<ref>{{cite book |title=Java puzzlers : traps, pitfalls, and corner cases|year=2005 |publisher=Addison-Wesley|location=Upper Saddle River, NJ [u.a.]|isbn=978-0-321-33678-1|author=Joshua Bloch; Neal Gafter|edition=5. print.|page=36|quote=The lesson for language designers is that sign extension of byte values is a common source of bugs and confusion. The masking that is required to suppress sign extension clutters programs, making them less readable. Therefore, the byte type should be unsigned.}}<!-- |access-date=6 October 2012--></ref>

Unsigned integers were left out of Java deliberately because [[James Gosling]] believed that programmers would not understand how unsigned arithmetic works.<blockquote>In programming language design, one of the standard problems is that the language grows so complex that nobody can understand it. One of the little experiments I tried was asking people about the rules for unsigned arithmetic in C. It turns out nobody understands how unsigned arithmetic in C works. There are a few obvious things that people understand, but many people don't understand it.<ref name="oracle.com"/><ref>{{cite web |url=http://www.artima.com/intv/gosling3P.html |title=James Gosling on Java, May 2001 |publisher=Artima.com |date=10 May 2001 |access-date=24 February 2015}}</ref></blockquote>

Java versions 8 and 9 added some limited built-in unsigned integer operations, but they are only exposed as static methods on the primitive wrapper classes; they operate on signed primitive integer types, treating them as if they were unsigned.<ref>{{cite web |url=https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html |title=Integer (Java Platform SE 8) |publisher=Docs.oracle.com |access-date=20 Apr 2023}}</ref>

===== High-precision decimal numbers =====
C# has a type and literal notation for high-precision (28 decimal digits) decimal arithmetic that is appropriate for financial and monetary calculations.<ref>{{cite web |title=decimal |url=http://msdn.microsoft.com/en-us/library/364x0z75(v=vs.110).aspx | work=C# Reference |date=19 August 2012 |publisher=Microsoft}}</ref><ref name="thedecimaltype"/><ref>{{cite book | last=Mok | first=Heng Ngee |title=From Java to C? : a developer's guide |year=2003 |publisher=Addison-Wesley|location=Harlow, England | isbn=978-0-321-13622-0 | chapter=9.5. The decimal type}}</ref> Contrary to the {{mono|float}} and {{mono|double}} data types, decimal fractional numbers such as 0.1 can be represented exactly in the decimal representation. In the float and double representations, such numbers often have non-terminating binary expansions, making those representations more prone to round-off errors.<ref name=thedecimaltype>{{cite book | last=Sestoft | first=Jon Jagger, Nigel Perry, Peter |title=C? annotated standard |year=2007 |publisher=Elsevier/Morgan Kaufmann Publishers | location=Amsterdam | isbn=978-0-12-372511-0 | chapter=11.1.7 The decimal type}}</ref>

While Java lacks such a built-in type, the Java library does feature an ''arbitrary precision'' decimal type. This is not considered a language type and it does not support the usual arithmetic operators; rather it is a reference type that must be manipulated using the type methods. See more about arbitrary-size/precision numbers [[#Advanced numeric types|below]].