Java vs C# - Experts points of view

Started by
28 comments, last by fraka3000 11 years, 8 months ago
My personal opinion is this:

If you're more interested in developing server applications, and cross-platform is a high priority, choose Java.

If you're more interested in developing client applications, particuarly on Windows, choose C#.



From a language standpoint, the 2 languages are almost identical. I would give C# the edge for having more modern language features, but only slightly.

The major difference is going to be in the library and platform support. Java has been around a lot longer and has more mature libraries and frameworks i.e. Spring. But C# is just closer to the metal for so many things. I have been using Java for many many years for many different things, but I have yet to see a single Java GUI application that approaches a standard of quality and performance that one can get from something like .NET that intuitively exposes the native GUI interfaces.

Mono is great, I've used it embedded in games developed in C++ as a high-performance "scripting" platform, and it worked beautifully. Unity3D does something similar to great effect. I've never really used it for standalone applications, so I can't really comment much on that.



Of course, if you wanted my true opinion, I would actually recommend learning C++ instead. It's quite a bit harder to learn, but the lessons you learn along the way will make you a better developer in my opinion. Since that's not on the table now I won't go any further, but if you want to know why I think so, I'll be glad to share ;)
Advertisement
I think it is important to add that C# has an amazing support for calling C functions from dynamically linked dll that basically involves writing 1 line of code (ok, 2 rolleyes.gif ).
From a pure game developing point of view this is quite important because you know that, if you were to find an hotspot to be uberoptimized you can easily go down to C without having to wrestle with weird tools and whatnot that most other languages seem to require.

Stefano Casillo
TWITTER: [twitter]KunosStefano[/twitter]
AssettoCorsa - netKar PRO - Kunos Simulazioni

I just look at it this way. I trust Microsoft more than I do Oracle. I also can use Mono over .Net so i dont have to trust Microsoft. Thus, I choose C# (mono) over Java.
I as fellow not so pro programmer have thought about creating Pacman in 3D, and while doing it maybe create seiries into youtube for other people to create own pacmans. I don't know if the concept of this idea is actually good, but while doing it, I most likely run into beginner like problems and could give tips to other people.

Anyways to the main point, I am now at the point of just creating design documentation for the project, and I too am at the point where I should choose the programming language. I have actually more leaned into Java because I would prefer using GLSL and OpenGL. Other reason why I chose Java over C# is, that there doesn't seem to be that many free game engines except XNA, and the problem I see with XNA is, that the person trying XNA-games need to have XNA-executables installed on their computer. Also the fact that porting models from Blender to JMonkey seemed to work without any kinds of problems.

So my advice would be, before asking what language to use, first decide what you're going to do. After that make some kind of list what kind of things you would need, and after you've sorted those out, finding the language / framework / tools you are going to need / use will be lot easier.

Other reason why I chose Java over C# is, that there doesn't seem to be that many free game engines except XNA, and the problem I see with XNA is, that the person trying XNA-games need to have XNA-executables installed on their computer


You should check out MonoGame (XNA API using OpenGL instead of DirectX) or SDLDotNet or SlimDX and of course Unity. SFML .Net wrapper just isn't there yet, but when it gets there, it will be an option as well. Of the three i mentioned, MonoGame, SDLDotNet, SFML (when its ready) and Unity are multi-platform.
I seem to have rather different opinion about the Oracle relation to Java. I've been working professionally only with C#/.NET, and I started doing academically Java just an year ago. So here are my two cents.

IMO, Oracle is the single greatest thing that could have happened to Java as a framework and language. From what I've read, Sun basically stopped introducing truly new features after 1.5, which was quite a while ago. Now, Oracle are introducing 1.7 and 1.8 within an year, maybe a bit more. It's not like the changes are big, but at least the language and the framework are visibly evolving.

Many people seem to compare C# and Java. Yep, that's one point of view. From my point of view, C# is C++ on steroids. The way I see it, it was meant (as a framework) be a a better COM (and thus quite appealing to C++ developers). And the way .NET integrates with COM is simply awesome. I've read that Microsoft tried to do this with Java, but Big Brother (Sun) said no deviant (non-standard-conforming) Java extensions should exist, so they took over the Windows implementation. As a result, we have .NET.

From user's point of view, Java sucks. Big time. Others told you about the updater. I see the freakishly ugly UI. Swing is the classical case of a bad multi-platform library. It has no true multi-threading (yeah, that slow download that was supposed to run in the background freaking hangs the UI thread). It looks like shit on any platform. It doesn't integrate with any platform-specific features. It doesn't use the standard icons of the operating systems. It may or may not use standard dialogs. SWT comes to the rescue, of course. It fixes most of the mentioned complaints, at least to some extent. It does feature stuff that is available only on a specific platform. The main problem is that there are some bugs in the drivers, and most notably that it is not a part of the standard Java distribution. JavaFX seems to be a nice idea, but I've never used it so I can't comment on it.

Like other people said, .NET is the complete opposite. It integrates well with Windows. It interfaces very easily with COM and C, so you have all the platform functionality at your fingertips. The downside, of course, it that all the magic is for Windows. But it's not so bad, as the Mono (mostly Xamarin folks) provide platform-specific UI toolkits for Mac OS X, iOS and Linux. So from a user's point of view, your application will look and integrate perfectly with the supported platforms.

Now, from a programmer's point of view. I've said some negative things about Java. This was about its UI toolkits. I do like the framework a lot. You can see a lot of thought being put behind it. I've said it before, I'll repeat it now. For me, Java is like an academic project - nice, intelligent, (somewhat) sexy, but also over-engineered and needlessly complicated at places. .NET and C# feel like professional work - there are hacks and imperfections; hooks are there for the more adventurous sort. Less stuff is forbidden. Decompilation is a kind of culture in .NET (at least the devs I know). I can't imagine myself programming on a .NET project without looking at the decompiled source of the library. You always get into the point where the documentation just sucks, or lacks sufficient detail. In Java you can do it as well, but the only working and free decompiler I know of (JAD) sometimes doesn't work. I've only seen Reflector fail at yield statements.

I don't know how else to put it. Java isn't as portable as they make it. Used to be the de facto standard for mobile phones. Has almost no integration with the OS (by design, so that it is "write once, run everywhere"... which is the case with .NET and Mono for what is implemented in the second, but you won't see that slogan anywhere, as it doesn't mean shit). Ironically, the only OS it integrates with (Android), uses different VM, so it ain't write-once, run everywhere. Compilation process in Java might be more pleasant and almost invisible(meaning you don't recompile the whole project in Eclipse as you do in VS). Assembly loading and linking in .NET is more advanced by leaps and bounds by default (you can load DLLs in different domains, so that you can have multiple versions of the same dll loaded in memory.. and used at the same time). Of course, OSGi does the same stuff, plus a lot more, but it is (unfortunately) not part of the standard distribution.

Anyways, wherever you pick, you will end up finding things you really hate. In the beginning you will be all "oh yah, events/inner anonymous classes are sooo KEWL", and "there are no memory leaks in .NET/Java yeaaaaah". And of course, you will find that both isn't so true. Programming, like a colleague said, is turning coffee into code. It is not a nice process all the time.

[quote name='Hiiri' timestamp='1342812386' post='4961421']
Other reason why I chose Java over C# is, that there doesn't seem to be that many free game engines except XNA, and the problem I see with XNA is, that the person trying XNA-games need to have XNA-executables installed on their computer


You should check out MonoGame (XNA API using OpenGL instead of DirectX) or SDLDotNet or SlimDX and of course Unity. SFML .Net wrapper just isn't there yet, but when it gets there, it will be an option as well. Of the three i mentioned, MonoGame, SDLDotNet, SFML (when its ready) and Unity are multi-platform.
[/quote]

Thank you for recommendations. I checked the engines quickly, and except for Unity, I felt like the importing animated 3d-model from blender to these engines would be a lot of work. If I understood correctly monogames 3D isn't completely ready, and I wasn't completely sure if skinning worked for it. SlimDX seemed a bit too low level api for me. I hope I can get something like couple of lines of code to load models and such, more of a complete game engine, kind of like Unity.

I did try Unity before, and I agree it is by far the most simplest game engine to get things to work with, that I have ever seen. The only problem I would have with Unity is that free version does have some limits, but most likely it would be features that I would never actually need to use, therefore it is probably usable.

The problem for me is, that I don't have that much knowledge about 3D-programming, and the reason why I chose Pac-Man to make 3D game is, that it wouldn't be too big jump from 2D to 3D for me. So what I am looking from the engine is:
- Easy way to import and draw animated 3d models from Blender.
- Easy way to detect collisions, this could probably even be 2D since the game is kind of 2D with 3D models.
- Reading inputs from keyboard
- Possibility to play sounds and music
- Shader programming, if I understand corect the best way to change colors of the ghosts when eaten by Pac-Man would be using shader programming.

For now what I have tried out, XNA, JmonkeyEngine and Unity are at least ones where loading and drawing animated 3d-models has been quite a simple thing. I might consider looking c++ engines aswell, since it seems there are a lot more of those. Panda3D for example looks something that probably works pretty well for my simple game.
I honestly don't believe that C# is going to die, but .Net probably will. C# is a wonderful, modern language with nice syntax and powerful features, and it would be a shame if another group doesn't pop up to maintain a multi platform version that is similar to Oracle. That's probably the reason why Java has been around so long, really.

Other than "different from Oracle", I support this point. :)

If I understood correctly monogames 3D isn't completely ready, and I wasn't completely sure if skinning worked for it


Yep, they're working towards 3D, getting many of the base mechanics solid before going there, which is why 2D for now works great. There have been a couple 3D games released with it already, but they mostly shored up with those individuals 3D code from what i understand. When it gets completed, it'll be quite nice. For now, if you're just working 2D, its solid enough to use.

Spawn a process and then get its process ID. You can't do this in Java.


???
Yes you can : Runtime.exec -> Process

This topic is closed to new replies.

Advertisement