For an articulate, blow-by-blow comparison of the two, see http://www.soften.ktu.lt/~mockus/gmcsharp/csharp/c-sharp-vs-java.html (but note, this article is dated 2001 and is substantially out of date).
CsharpLanguage and JavaLanguage:
- Both have single ImplementationInheritance and multiple InterfaceInheritance.
- Both have automatic GarbageCollection.
- There is a broad overlap of common operators and keywords (41 of 43 operators; 38 of 50 keywords, 46 if you allow for synonyms).
- Java is defined through the JavaCommunityProcess. C# is an ECMA standard.
- PassByReference
- Java only has CallByValue.
- C# has CallByValue and CallByReference. CallByValue is the default. Marking a parameter with the ref keyword indicates that it is passed by reference. Marking a parameter with the out keyword indicates that it is returned from the method.
- Delegates
- More powerful than FunctionPointers (which don't exist in Java).
- Represents a bound method with a given signature and invokes it polymorphically.
- C# has a built-in delegate mechanism.
- Java uses AnonymousInnerClasses for the same uses
- Described as "fully object-oriented", which is a totally meaningless statement. Anonymous inner classes are arguably more "object oriented" than delegates.
- See http://www.onjava.com/pub/a/onjava/2003/05/21/delegates.html for delegates in Java.
- MicrosoftWindowsApi
- It may be easier in C# to design for Windows.
- This may not be a universal advantage.
- OperatorOverloading
- C# can overload some operators.
- The C# String type has its == operator overloaded to provide value semantics.
- When you overload ==, and != will work as expected.
- When you overload ++, both prefix and postfix forms work as expected.
- switch on "strings"
- This was added to Java 7. Previously it could be done in Java using a series of if () {} else if () statements.
- GoTo
- C# has it; Java doesn't.
- Does C# have labelled breaks? No, break and continue can't have a label.
- struct
- In C#, a struct is a ValueObject allocated on the stack.
C# structs are dangerously and cryptically implemented: See CsharpQuestions (search on word 'struct')
- You can use NullableTypes to allow such types to support null values.
- Java has no analogue at the language level but the JVM is able to allocate objects on the stack when it determines that they do not live longer than the method activation that creates them.
- Preprocessor
- C# has a preprocessor similar to the CeePreprocessor.
- You can't do some things like #define private public. It's simply a means to create symbols for conditional compilation.
- Attributes
- Allow you to embed meta-data in the compiled binaries.
- This is an enhancement of reflection.
- Attributes were introduced in C# but are now also supported in Java 5.
- Calling native code
- ExceptionHandling
- Properties
- In Java, getName and setName are methods for manipulating properties, per JavaBeans.
- In C# the property Name wraps get and set methods and is explicitly defined as a property.
- (Contributors: BrettMcNamara)
- Properties can be little misleading, though, as they can be mixed with data members within methods of same class. (For other classes, this is not a problem because there should be no public data members.) One can easily create a property that performs a HTTP request to return value, somehow forget that it's not a data member, and then wonder why performance is so bad. To some extent, this can be fixed by profiling, but anyway that's unpleasant. (See also SyntacticallyEquivalentMembersAndProperties)
- Both languages support BoxingConversions.
- C# autoboxes values to heap-allocated values of the same type.
- Java autoboxes values to heap-allocated objects of a different type. This complicates reflective code.
- Closures
- InnerClasses
- EnumeratedTypes
- C# has enumerated types similar to those in CeePlusPlus. Each enumerated value resolves to an integer constant.
- Java's enumerated types are actually immutable classes. Each enumerated value is an immutable object, complete with polymorphic methods.
- Events
- C# has language support for publish/subscribe style events
- Java uses coding conventions to implement publish/subscribe events with listener interfaces and methods to add and remove listeners.
- Generics
- C# has real generic types: generic types exist at compile time and at runtime.
- Java generic types are compiled away: only non-generic types exist at runtime.
Summary:
- slightly more ObjectOriented than JavaLanguage
- in what way? just BoxingConversions? or am I missing something? EverythingIsa object.
- sorry to repeat myself. in what way? primitives are still primitives, unless they're boxed. This is true in Java, also. No, they aren't primitives; they inherit from object. They are implemented using primitives, and they are optimized using a mechanism called BoxingConversions Using your reasoning, everything is just ones and zeroes, which isn't a really useful model of things. You could even go as far as saying everything is just "energy," and refuse to accept further abstraction. However, programming is all about abstraction.
- Slightly less ObjectOriented than JavaLanguage. Doesn't support true InnerClasses, therefore it doesn't support closures at all. Also structs are not objects; you cannot force clients to call a proper constructor on structs (although structs allow constructors), and you cannot test for null. Such a bad design decision is especially significant in System.DateTime struct which cannot be nullified. Mapping a datetime field from a database to a datetime member in CeeSharp is therefore impossible whereas in JavaLanguage, Date objects can simply be null.
- Both of these issues are addressed in v2 of the language - AnonymousMethods provide fully-fledged closures (with full access to the closure's outer variables - no stupid final restrictions like in Java), and the non-nullability of value types is address with NullableTypes, which allow you to mark any instance of a value type as being nullable, without boxing it, and hence giving up the performance advantages of a lightweight, stack-based object (this is mostly just a thin veneer of SyntacticSugar over the System.Nullable<T> struct, with some compiler magic to 'lift' operators from the underlying type, and various other things [now, if only they'd do something similar to provide non-nullable objects, so you can deal with things without having to sprinkle null checks all over the place...])
- may be easier for MicrosoftWindows application development
For the record, the snide remarks above are by me. Don't mean to be too rude, I just really have a hard time seeing the alleged improvements from JavaLanguage to CeeSharp. To me, as a Java programmer, C# has exactly two things that I envy: close integration with the MicrosoftWindowsApi, and structs that can be allocated on the stack. So much of what I see is 'save four keystrokes' (isn't that what editor macros are for?). And so many of the alleged improvements to the VirtualMachine, pardon me, CommonLanguageRuntime, seem like old hat. Multiple languages in one program? Woohoo! I'm not going to take the stance that this is a management nightmare; if properly managed, it's wonderful. But I've had reasonably large Java runtime programs written in a combination of SchemeLanguage, JavaLanguage, and PythonLanguage, and never had any problems... and never really longed for any other languages, except PerlLanguage. I want to be converted, if for no other reason than I want something new to play with... but I just can't get CeeSharp or DotNet to excite me. -- AdamBerger
- I think the fact that Microsoft makes an active effort to make the CLR a good target for multiple and diverse languages is a very significant advantage. Sure, you can compile SchemeLanguage to JVM bytecode, too, but whereas the JVM has some things set in stone that make this necessarily cumbersome or inefficient, Microsoft has (or so I've been told) actually changed their VM in response to issues raised by people who wanted to target the CLR with Scheme. This means that DotNet is a universal platform, whereas JavaPlatform is just a platform for JavaLanguage, which, it has to be said, has many weaknesses.
CeeSharp has more features than JavaLanguage, and is therefore more complex. You'll not see these features from a high level. What about CLR (CommonLanguageRuntime) attributes for instance? Do you really understand what they are about?
Nope, I'm not sure I fully do. Can you elaborate more? My (limited) understanding is that the CLR's 'big feature' is that it allows interaction of multiple languages (hence the CL), allowing things like classes in one language extending and using those in another. This isn't a property unique to the CommonLanguageRuntime, though. You see it anywhere a single bytecode is expressing more than one language... my example above was the JavaVirtualMachine. Are there other things I'm missing?
Sometimes 'save four keystrokes' is very important, not because it makes code easier to write, but because it makes code easier to read. In JavaLanguage, pulling an Integer out of a List ends up looking way too complicated when you read the code that does it. BoxingConversions would help a lot with this. -- ChristianTaubman
SyntacticSugar is one of the things that make the two languages interesting. I'm more comfortable with JavaLanguage, but I like how CeeSharp is more "Principles Atheist." Java polices you a little by not providing functionality that could be considered bad coding practice to use. C# gives you the right to do those things (GoTo, OperatorOverloading), encouraging you not to shoot yourself in the foot, but letting you govern yourself, so to speak, as far as what is "good" programming and what is "messy" programming.
Well, you get Perl RegularExpressions.
Indeed. In JavaLanguage, you need a separate package for this (the best I know of is Jakarta ORO). I also envy CeeSharp developers the built-in API for bytecode modification, whose closest approximation in Java is IBM AlphaWorks?' JikesCompiler Bytecode Toolkit.
Perl RegularExpressions are in JDK 1.4 in java.util.regexp
And does anyone but me want to call it C Hash?
I prefer to call if D-flat.
Here's another vote for C Hash.
"C-pound."
I think they should spell it with a Unicode sharp sign -- as opposed to a plain hash -- if they insist on calling it that.
"C Octothorpe"
Is the sharp(#) overlapped plus-plus(++)?
InTheory.
I think this whole page misses the point. MicroSoft isn't pushing DotNet as a better way because CsharpLanguage is significantly better than JavaLanguage. It's because they claim the .Net environment (CeeSharp and the other languages, VirtualMachine, runtime libraries, etc.) is better than the Java environment. CsharpLanguage is not obviously much worse than JavaLanguage. That's all MS needs from it.
To some extent, I think this may be the most insightful comment on the page. On the other hand, the page is'' CsharpVsJava, so we have to find some way to compare them. As to 'not being worse' being good enough... well, from a marketing point of view, I'll accept that. But from a developer's point of view, it's kind of a disturbing attitude.
- Note, however, that this is not necessarily the attitude that Microsoft has, and that CeeSharpLanguage is not necessarily just "not obviously worse". I, for one, think that CeeSharpLanguage is the better language.
And, moreover, I'm not at all convinced
DotNet's environment is that revolutionary. (Is there already a page like DotNetVsJava
?, or shall we move some of this over there? [Well, we do have
DotNetWillKillJava,
EjbVsDotNetNews,
JavaAndDotNetPhilosophies.]) It seems like much of .Net's astounding new capabilities are things I've been doing, on a daily basis, in Java. And the Java APIs, while a few things are missing from the core (like
RegularExpressions, mentioned above
[RegExps are in fact in the core, as mentioned above]), do have the advantage of a lot more maturity... and today, if not tomorrow, much more third-party support.''
- Nothing about DotNet is all that revolutionary. Most of what is good about it has existed for several decades. The news is not that it's revolutionary, but that it isn't; these good things are finally being accepted by the masses.
I agree most of what can be done in
DotNet can be done in Java. But not out of the box; there's a certain amount of installation and systems integration needed to get things working in Java (that's the downside of the "much more third-party support").
MicroSoft has also taken the opportunity to do a lot with areas of .Net that aren't anything much to do with language or standard libraries: a very neat cache (heavily used in
AspDotNet), assemblies (so easing version problems), etc, etc. Nothing innovative in the individual items, but the whole is, IMO, and the evolution is controlled by one company, making uniformity much easier to achieve (which is good and bad, of course). For instance, you're pretty much required to use
VisualStudioDotNet. Good: all add-on developers have one platform to aim at. Bad: other
IntegratedDevelopmentEnvironment vendors have huge barriers to entry.
You are not required to use VisualStudio (not even close)!.
pretty much required to use VisualStudioDotNet. You are? In what way?
Actually, the luscious support for CeeSharp provided by VisualStudioDotNet is a distinguishing virtue all on its own.
I might have been wrong. It seems it's not strictly true (it seems that the SDK is enough to support a compiler, etc.), but there're a lot of integration and DotNet-specific tools in VisualStudioDotNet which would be difficult to compete with, so I think the barriers-to-entry-point still stands.
There's an OpenSource IntegratedDevelopmentEnvironment for CeeSharp which is completely written in C#: http://www.icsharpcode.net/OpenSource/SD/Default.aspx
Well, I'm not a fan of IDEs so there may be some bias, but I certainly don't feel that I'm missing out by not using VisualStudioDotNet. I also can't think of anything in VS.Net that other vendors wouldn't be able to compete with. Anyway, this is about CeeSharp/JavaLanguage, not VS.Net/Java. For what it's worth, I think the language debate is largely pointless, painfully emotive, and almost always carried forth by programmers who have very little experience of the other language.
"You don't need [VAR parameters] in an object-oriented program." If I have to interpret this then I had to paraphrase it with "VAR parameters aren't required to write object-oriented programs." I find this a very unenlightened view - higher level languages aren't necessary to write programs; we could still manipulate bits and bytes directly. Why the change then? Because higher level languages make things easier for programmers. And if VAR parameters make things easier in C#, then why don't use them in such cases?
PageAnchor: generalization
Well, as a JavaLanguage programmer I've been forced to work with AspDotNet / CeeSharp. I liked it. As Java is built on the memory of CeePlusPlus errors, so C# used the experience with Java for improvements. Indeed, not all are good (about 68% are good). ASP.NET has a very similar ObjectModel for building a DeskTop application. I find it very helpful.
We should also remember that it is not CsharpLanguage vs. JavaLanguage, but DotNet vs. IbmCorporation vs. Oracle vs. Bea and friends.
One BIG problem with JavaLanguage/JavaTwoEnterpriseEdition is over-generalization. Generalization is basically good when it is essential and minimal. Remember that OO code reuse has not reached the highest expectations. (failed for business logic, if you ask me). Too many choices killed CeePlusPlus. (The reports of C++'s death are greatly exaggerated.) Let's not make the same mistake with Java. Why does Java need two user interfaces frameworks? I don't like all this Java-naming scheme. Make java.swt (my hope) -> java.ui, make javax.jms -> java.messaging. I prefer uniting all JAXP JAXB JAXS JAXX into java.xml and make one SIMPLE standard. See how well it is done in DotNet.
I prefer the Unix model of having a ton of small programs (analogy to the small APIs you mention) that do exactly what they're supposed to do very well, and nothing more. You take those small pieces of functionality and combine them and you get something extremely powerful. Yes if you want to do a specific task, you need to comprehend the technology you need to use. Throwing separate APIs under a common namespace only hinders this.
CsharpLanguage is better at managing memory. We're developing statistical applications for analysis of MicroArray? and MassSpec? data (that's genes and proteins). When a single dataset has 1000 columns and 50000 rows (all doubles), memory means a lot. Then, you generate even more data as part of the analysis. We compared JavaLanguage to CsharpLanguage and found that Csharp used less memory.
- I think these are implementation features rather than language features.
- Implementation features is very important when the language is made and controlled from the very same company who implemented it. If Sun java implementation sucks that's telling something.
- What is it telling? How is using less memory "better at managing memory". What if the garbage collector was much faster but used more memory? Is there only one implementation of the Java VM? How much less memory did Csharp use than Java when storing a giant array of doubles? Why is the quality of the entries on this page of such low quality?
Discussion moved to CsharpLanguage.
See CsharpLanguage, CsharpFeatures, CsharpLanguageDiscussion, HolyWar
CategoryJava CategoryCeeSharp CategoryComparisons CategoryProgrammingLanguageComparisons
Csharp Vs Java