What could C# learn from Java?

tags:

c#
java

views:

459

answers:

+7 Q:

What could C# learn from Java?

I've been a "Microsoft developer" ever since I started programming... I started out by learning QBasic then ASP & Visual Basic and finally I moved on to learn VB.NET, ASP.NET and C# which is now my primary language. Still I've always wanted to learn something like Java or C++ to see how what the "other side" is like, and to learn the pros and cons of each platform. The only problem is that I never found the time or opportunity to pick up another language.

My basic understanding is that Java and C# have a lot of similarities as well as a lot of differences. Coming from C# I'm mostly interested in what C# could learn from Java, or put another way, what I'm missing out on.

+12 A:

Nothing, C# based itself on Java :)

prepares to be ridiculously downvoted

Noon Silk 2009-08-25 06:46:46

+1 for 'prepares to be ridiculously downvoted'

rahul 2009-08-25 06:47:24

I don't agree that it is plainly based on Java, but it certainly took inspiration from it. Many of the Java features were adapted and others were left out for a good reason (eg. checked exceptions).

Filip Navara 2009-08-25 06:48:44

Agreed on checked exceptions, I was overjoyed to find them gone in C# :) I certainly think C# has done quite well from it's basing of Java, and is now headed to the darkside with it's desire to be more like JavaScript :P

Noon Silk 2009-08-25 06:50:33

Surely both languages has evolved since the inception of C# so even if C# somehow managed to get all the good features from Java (which I doubt) from the start, they might have a thing or two to teach one another now.

JohannesH 2009-08-25 07:01:00

Actually, C# is pretty far from Java. C# has a much more "European" flair to it. Which makes sense: Java was designed by Americans with C++, Smalltalk and Lisp backgrounds, C# was designed by Europeans with Pascal and Modula backgrounds. C# is mostly Modula-2 with C++-like syntax, and a pinch of Eiffel and Oberon thrown in. The deep integration between IDE and language is lifted straight from TurboPascal and Delphi. The only thing that is even remotely Java-like is the object system, but even that has a distinct Scandinavian/Simula/Beta flair about it.

Jörg W Mittag 2009-08-25 11:36:15

As someone with lots of Java and no C# experience, I think I can say that you're right simply based on observing C# questions here on SO where I think "Well, in Java the answer would be X" and most of the time I see that in C# the answer is X, with minor variations in wording, spelling and syntax. This goes for both the language and the class library.

Michael Borgwardt 2009-09-22 16:39:59

+9 A:

I think C# would be better off if they enforced the one public class per file and forced you to put your code files in a directory structure which matches the namespace (i.e. "package"). This is one thing I really like about Java that frustrates me in C#, especially when people start moving .cs files around, and putting multiple public classes in one file.

Andy White 2009-08-25 06:49:12

That's an absolute frustrating thing in Java. Hundreds of folders, most empty and absolute useless. Refactoring is a pain too!

Scoregraphic 2009-08-25 06:53:28

I believe that has more place in StyleCop than the language specification itself.

280Z28 2009-08-25 06:57:11

If you have hundreds of empty folders, I don't think you're doing it right.

Andy White 2009-08-25 06:59:16

Agreed, I should have written that an empty folder in my view is a folder without classes inside (subfolders may exist). Namespaces are often like com.company.product.library where most classes are in the library subfolder. But why do I need such a long stack of folders?

Scoregraphic 2009-08-25 07:05:44

I see your point, but I still think it's much easier to find any arbitrary Java code file than a C# file. If you look at the Java package, you know exactly where to find the file, whereas with C# the file can literally be anywhere. I think the whole concept of a namespace is the main culprit for the verbosity. Namespaces are a tradeoff between convenience and uniqueness.

Andy White 2009-08-25 07:12:46

Why would you force your folder structure into a single view of the project (the namespace view). Any decent tool will let view view your project in this way (and other ways) without forcing a folder structure.

Robert Jeppesen 2009-08-25 08:16:51

@Andy, @Scoregraphics: with a decent Java IDE you don't see the "empty" folders unless you go looking. (And most of the time you don't even notice the package structure. Type a class name, "complete", if there's ambiguity select the class by FQN, and the "import" is magically inserted at the appropriate place.)

Stephen C 2009-08-25 09:57:18

This is one of the worst design decisions in Java. They go through all that trouble with their `.class` and `.jar` files, their `package`s, `import`s, FQNs, name resolution algorithms, *all* in order to decouple **name**s and **file**s in the language. And then they *require* you to couple them. There both advantages and disadvantages to the image model (Smalltalk, Factor, some Lisps) and the file model (everybody else), but Java elegantly manages to combine *both* models in such a way that you get all the disadvantages of both (plus some that are unique to Java) with none of the advantages.

Jörg W Mittag 2009-08-25 11:45:38

I guess there are just two camps on this. I like the coupling of the code to the physical layout, it's just one less thing that can be done in an unexpected way.

Andy White 2009-08-25 17:18:04

+4 A:

Personally I would have preferred to use the Java style for properties. I don't like the fact that properties in C# looks exactly like fields and yet have entirely different semantics. By making it clear that properties are really just methods there is no illusion and less risk of mistakes.

Brian Rasmussen 2009-08-25 06:49:44

I've disliked C#'s properties ever since I first started in it (8 years ago now). But these days I'm over it, and I think they're great. I do wish you could DataBind to regular fields though.

Noon Silk 2009-08-25 06:53:39

If you give direct field access to other classes, you may not have understood OOP. So expect every "field" to be a property.

Scoregraphic 2009-08-25 06:55:49

C#'s properties are one of the reasons I have to chuckle to myself when I see people writing Java code. You prevent mistakes by following the through-and-through consistent naming conventions and realizing that properties are simply an improved field with the ability to have logic/validation. When properties are written as methods, is suggests that object traits are actions, and that is a far worse semantic mistake that properties/fields having similar appearance.

280Z28 2009-08-25 07:02:23

@Scoregraphic: That's a fair point, but the problem exists even within a single type, so this is not tied to encapsulation or the lack thereof. You cannot tell if Foo.X is a field or a property, and the difference does matter in several cases. Furthermore you can change X from a field to a property or vice versa and in some cases that will have side effects.

Brian Rasmussen 2009-08-25 07:04:40

What does direct field access have to do with OOP? Surely OOP does not preclude mutable classes? In those cases, whether or not you (after being prodded in one direction or the other by your language's designer) instruct the compiler to emit a CALL before the MOV is surely an implementation detail.

Richard Berg 2009-08-25 07:07:16

@Brian: Agreed, you may not distinguish them while writing code. But if your property has side effects, shouldn't it be a method then?

Scoregraphic 2009-08-25 07:10:15

@Scoregraphic: Yes, it should but unfortunately that is not always the case.

Brian Rasmussen 2009-08-25 07:12:44

C# implements the uniform access principle ( http://en.wikipedia.org/wiki/Uniform_access_principle ) by making properties look like fields. You could say that's a good thing - it makes it easy to replace a field by a property with a getter and setter without the need to change the rest of your program, and so makes you feel less guilty for using public fields...

Jesper 2009-08-25 07:16:52

@Jesper: But that is not true, because fields and properties are not the same. E.g. properties cannot be used with ref/out, so you may have to change your code if you do that. Also a Foo.X is guaranteed to equal Foo.X if X is a field. There is no such guarantee if X is a property, e.g. DateTime.Now equals DateTime.Now most of the time.

Brian Rasmussen 2009-08-25 07:47:29

@Jesper: Actually, C# *still* violates the Uniform Access Principle, because while properties and fields look the same, fields/properties and methods do not. The *correct* way to fix Java's violation of the UAP is *not* to introduce *yet another* access method, but rather to *remove* unnecessary access methods. Newspeak works just fine with *only* methods, ECMAScript works just fine with *only* fields. There's really no need to have both. (Fields are just getter and/or setter methods. Methods are just fields with executable code (delegates, lambdas) in them.)

Jörg W Mittag 2009-08-25 11:52:40

+10 A:

Should support Java like Enums, In C# they are just name for numbers !!

Prashant 2009-08-25 06:52:03

Well...it's an enumeration...if you need the Java enum behaviour, use a "real" class instead.

Scoregraphic 2009-08-25 06:57:31

It's a fair point. "Real" classes don't get the nice syntax sugar, the [Flags()] attribute, etc.

Richard Berg 2009-08-25 07:08:42

`[Flags]` isn't necessary in Java, thanks to `EnumSet<T>`. It's safer and integrated into the Collections framework, double win. The only bad thing I can come up with about Java enums is that enum fields/variables are nullable.

gustafc 2009-08-25 08:52:51

I actually wish Java's enums were just names for numbers.

izb 2009-08-25 09:27:43

@izb: :)

Prashant 2009-08-25 09:48:20

@gustafc - good point, the design of EnumSet<T> is way better than System.Enum. Unfortunately, the kinds of applications where bitwise operations are desireable are exactly the ones where Java's need to box/unbox generic collections is most painful.

Richard Berg 2009-08-25 16:14:07

+2 A:

checked exceptions
package visibility for submodules. AFAIK you can only have one module per assembly. I mean a group of tightly coupled classes which can see each other but should be hidden from the outside world.

2009-08-25 09:12:43

I think checked exceptions were explicitly left out after observing Java's experience with them.

duffymo 2009-08-25 09:35:43

@duffymo: maybe ... but some people think that was a mistake. I >>like<< the idea of being forced to think about exception handling.

Stephen C 2009-08-25 09:59:24

Checked exceptions were left because there exist programming languages for the .NET framework which do not support checked exceptions anyway. So for compatibility reasons, it was left out.

Scoregraphic 2009-08-25 11:18:34

Checked exceptions are an example of what Erik Meijer calls "type honesty": that a type signature should not lie to the programmer. If the type signature says `int foo()`, then the method should *really* return an `int`. But it doesn't: it returns either an `int` or not (i.e. `null`) or an Exception. And that fact should be recorded in the type signature. E.g. in Haskell the return type would be `Maybe Int` if it could return `null`, `Either Exception Int` if it could return either an exception or `int` and the combination of both would be something like `Either Exception (Maybe Int)`.

Jörg W Mittag 2009-08-25 12:08:58

Of course, that does not mean that the way in which checked exceptions are implemented in Java is a good way (it isn't). But the fact that the type signature makes it clear that something bad could happen, and that the type system forces you to deal with that, is a good thing. It's just too restrictive in the way it is implemented in Java. Maybe anchored exceptions would be a better choice, or maybe the Maybe and Either types from Haskell. The latter can be implemented in both C# and Java (yay, Generics), but the problem is that the rest of the code (i.e. standard libraries) doesn't use them.

Jörg W Mittag 2009-08-25 12:16:38

@Jörg: Wouldn't we get a sort of "type honesty" in C# with code contracts?

JohannesH 2009-08-29 12:21:04

Yes, in some sense. It's not as powerful as static typing (especially since the Halting Problem means that there is no guarantee that contracts can be verified at compile time), but it's certainly better than just HTML documentation. Interesting side note: .NET actually *does have* checked exceptions, in a funny sort of way! The .NET documentation on MSDN contains exception tables which list for each method the exceptions it can throw and why. And indeed, the Spec# team actually generated a lot of their contracts for the BCL automatically by scraping the HTML off MSDN and parsing those tables!

Jörg W Mittag 2009-08-29 17:21:41

Yes that's true... Also since contracts are an opt-in feature they won't be able to give you any guarantees in the same way that a required language feature (i.e. checked exceptions) would be able to. Though I'm not sure whether checked exceptions are required by Java... Are they required?

JohannesH 2009-08-30 23:44:26

You can also use unchecked exceptions. But if someone *else* used checked exceptions, you *must* handle them. And one of those "someone elses" that *do* use checked exceptions is the standard libraries. There's a nice variant of checked exceptions called "anchored exceptions", which allows you instead of listing every single exception to declare "throws like `foo()` and `bar()`, and also throws `BazException` but handles `QuuxException`.

Jörg W Mittag 2009-08-31 01:46:15

stephen c: you haven't used java enough then :) duffymo is completely correct. c# learned that checked exceptions caused bad coding approaches, and were generally not useful, hence they are gone! hooray!

Noon Silk 2009-08-31 04:30:54

c# does not have checked exceptions because Anders Hejlsberg said so: http://www.artima.com/intv/handcuffs.html it was a deliberate and well-thought-out exclusion.

Rex M 2009-08-31 04:35:50

I just noticed the big discussion the checked exceptions generated.I like them because they are DBCish and the Design By Contract (strict contracts) style is close to me,nothing special.However I've read the Hejlsberg article and I don't buy a word of it. (Actually it's not the first Hejlsbergarticle what I don't like, the one on the virtual methods was strange for me too, maybe because I'm a C# noob.)

2009-08-31 09:16:45

Anders explains the trouble with checked exceptions: http://www.artima.com/intv/handcuffs.html

Robert Claypool 2009-09-22 16:37:50

C# obviously learned a great deal from Java, just like Java did from C++. They've traded back and forth in both language features (e.g., Java taking annotations from C#) and ancillary projects (NHibernate, NAnt, Spring.NET, POJO/POCO based development, etc. all have their origins in Java).

But I'm afraid that Java's not advancing anymore now that Sun lost market and people and has been sold to Oracle. I don't see anything coming out of Java or vendors that looks terribly new right now. Java 7 has been a long time coming, and it's catching up with closures and other things.

I think whatever energy is left in language development has passed to dynamic and functional languages.

The only development that I'm aware of that could change that is Rikard Oberg's Qi4J. He's so out there. It's just going to be a long time before it becomes mainstream, if ever.

duffymo 2009-08-25 09:41:58

+2 A:

Anonymous interface implementation - Java does it, C# does not (yet).

For example:

// C#

interface IRunnable
{
    void Run();
}

var runnable = new IRunnable()
{
   public void Run()
   {
      Console.WriteLine("Running...");
      // Do your running
   }
};

runnable.Run();

Travis Heseman 2009-09-22 16:31:12

But in C# you use delegates for that. Java's anonymous interfaces are only(?) there to compensate for the lack of delegates.

erikkallen 2009-09-22 16:46:53

I'm a heavy user of delegates, but I still come across times it'd be nice to inline a interface implementation rather than actually create a class. It's not needed, since I can always use some OO design pattern. I really got used to this feature in Java and wish I had it in C#.

Travis Heseman 2009-09-23 12:08:08

ansaurus

tags:

views:

answers:

What could C# learn from Java?

related questions