Should we choose Java over C# for a new project? [duplicate]

Question

We have a team of .NET developers (C#) with a range of experience from 2 to 6 years. Over the last few years we have been developing Silverlight, ASP.NET MVC, and WPF applications. However, there is a new two year project which means we will develop a HTML5 application on Linux.

The company I work for would like all developers across their offices to use the same programming language which is Java. Although there is talk of using Mono but using the same language and sharing modules, services, etc. already created in Java is the main reason for moving to Java.

Some of the developers here are upset. How do I find something positive in moving over that will convince the other developers?

There will be a training budget, but the thought of learning to work with Java libraries and a new platform (Linux) will be scaring a lot of the guys.

What should I do?

Answer 1

This is coming from a developer who has worked in both the .NET and Java frameworks.

The ones who are getting upset and mad about this situation are either shortsighted, lazy, or just stupid. Before I get downvoted hear me out, it is not because I feel Java is a superior platform to .NET, actually its quite the opposite. The C# language is MUCH better and EntityFramework with LINQ is REVOLUTIONARY IMHO.

The reason they should embrace this decision is because having 2+ years of experience in both frameworks has opened up doors for me. I can't go to the bathroom without head hunters pleading with me to talk to them about the pile of job opportunities that they have lined up.

When the job markets are 45% - Java, 35% - C#/.NET, and 20% - (PHP, Perl, Ruby, etc...) you have essentially qualified for almost 4/5ths of the available job openings at any given time.

And even if money isn't your chief motivator, then not becoming complacent is. As soon as you start to feel comfortable that's when you NEED to shake things up and try something new. People who can't bring themselves to step away from their comfort zone are either shortsighted or dominated by fear of the unknown and that isn't what I look for when interviewing developers.

Lets face it, I am working quite happily in Java now -- I am making good money and if this doesn't work out I have the security and peace of mind to know that I have a lot more opportunities then many others I will be competing with. Do I miss C#? yeah, but in the end I got mouths to feed and am just trying to make my way.

Answer 2

Firstly, Linux as the new platform is not that big of a problem. Java is based on the JVM which does a pretty good job on hiding the system and the hardware. If you need to dig into the OS, than neither Java nor C# are the language of choice in my opinion. It's much like developing PHP. You can do it with a webserver on both Linux and Windows, and in almost all cases there aren't any differences during runtime due to the system it's deployed on.

When you are developing web applications with Java, especially enterprise web applications, you'll probably use Java EE, so you'll have to use a container for it (JBoss, WebSphere, GlassFish, etc.). These can be run on Windows or Linux, it doesn't matter. Our production systems here use Red Hat Enterprise Linux with JBoss, while most developers have Windows 7 systems and this inhomogeneity never caused any trouble.

Switching to Java from C# isn't really complicated, too. The languages are quite similar in most aspects. You'll really miss some features like Properties and LINQ, but this is really a minor concern.

A much bigger concern are the APIs. Java and J2EE done right differs quite a lot from the .NET (web-)technologies. You should put serious effort into learning JPA and EJB best practices (if you are using Java EE, that is, JPA can also run standalone). I also advice to use EJB 3.0 as the pervious versions are totally overengineered and now have been simplified. Sadly, most Java development these days is still a venture through the XML-Hell. Although convention over configuration has been put into place in the newest releases of most APIs, there's still a lot of XML to write. This is especially true to web-development (JSF for example). Please note that in this context I am talking about configuration issues and not about declarative UI development.

As far as web-technologies are concerned, I'd advice you not to use JSF (which is propagated as a standard), as it is complicated and overengineered. It might get better with the next releases. I'd rather use Apache Wicket or Tapestry, which will save you a lot of headaches, especially if you'll have the need for custom user controls or rich clientside scripts.

As for the interoperability: If the existing services are coded against industry standards (REST/SOAP) then you probably have no problem consuming them with .NET. However, if you'll have to use existing libraries and modules, then it's probably better to use Java, in order to keep reuseability high (DRY) and for the sake of homogeneity.

My advice is to keep the environment of the customer clean. Use Java, the language switch isn't that complicated. Train on the APIs you want to use extensively. I know developers are going to swear, because they'll be missing LINQ, and because they'll be writing a little more boilerplate code, but you can definitely transfer lots of experience (especially on the modelling part) to the new environment.

Edit: Regarding the APIs of choice, some people (@TMN for example, thanks for pointing it out) suggest to skip EJB altogether and to adopt Spring Framework and Hibernate. Hibernate can also be used as a JPA provider. This is certainly not bad advice.

Answer 3

Why not use Mono?

I have actually been successfully using Mono and .NET 3.5 on linux for commercial software for the past couple of years. There is only a few things that are not fully supported by Mono. However our team have generally made the best of it and we're extremely happy with the results.

Switching frameworks is non trivial

I personally know both Java (Spring MVC, J2EE, WebSphere, etc) and C# (3.5, 4.0, Castle MVC, ASP.NET MVC, NHibernate, etc). The switch between using ASP.NET and Java is anything but trivial.

Pure code yes very similar and easy to switch between Java and C# (no Linq obviously, however there is functional java).

Loosing combined experience in .NET frameworks

However what you loose if you decide to switch is your combined experience with your current frameworks and will need to start from scratch learning a new framework. Which will cost time and money in slow project velocity as your developers learn a new framework.

Evidence based scheduling just got a lot harder

This is the most non-trivial part of the equation, not only will you no longer be able to successfully calculate project dates as developers will not be able to judge if a portion of the project will work the way they want it to. So you can expect that when a developer would say "If I was using .NET I would expect it to take X days with an accuracy rate of 80% either way. But seeing as I'm using an unfamiliar framework perhaps that accuracy rate should be 160%".

Do your developers WANT to learn a new language/framework?

The key here is assuming that your current developers WANT to learn a new framework. If not they may not give learning Java/J2EE a good shot and would give up at the first sign of change or resistance to how they know how to do it in .NET.

Developers may decide to leave

If you don't have developer buy in, then you may end up with developers leaving completely. Its sad, however that maybe the situation you'll be faced with considering that there is a pretty widely used open source alternative in Mono.

Answer 4

I've personally gone from Java to C# and back again to Java/Clojure so can really sympathise with your team. People naturally resist change, particularly when they fear that their hard-earned skills will become worthless or less valuable.

However there are plenty of positive ways to look at this:

• Java and C# are actually, in the grand scheme of things, very similar at a language level. Not particularly surprising when you consider that C# syntax was largely based on Java (with various additions). Skills in one mean that you will become proficient in the other pretty quickly (took me only a couple of weeks to switch either way), and it looks good on your resume not to be seen solely as a "one technology person".
• Once you get beyond the minor syntactic differences of the difference comes in using the different frameworks (J2EE vs ASP.NET vs. WPF vs. Swing etc.). However if you're developing a new HTML5-based stack you will probably need to learn new frameworks anyway. So is this really that big of a deal? I'd treat it as an opportunity to learn new ways of doing things that will make you a better programmer in the long run.
• The Java platform is great and has a lot going for it. The engineering in the JVM is amazing, there is a fantastic ecosystem of open source libraries, the tooling is excellent (Eclipse, Maven, EGit are the ones I use most), you can write genuinely cross-platform solutions, there's a huge amount of innovation happening (especially in the framework and new-JVM-language space). Sure it's different from the Microsoft stack, but is certainly at least as good overall.
• There are plenty of great things on the Java platform for people to get excited about. You're not tied to Java-the-language in the future. Example: Android, Scala, Clojure, are all areas of real innovation and opportunity.
• Linux is a great platform to learn and work on. Your team might find it different and unusual at first if they haven't had experience before, but it has a lot of great things going for it. Surely every self-respecting developer can see the value in learning a new technology?
• You also don't have to give up Windows - I personally use Windows as my desktop development environment of choice (with the Eclipse IDE for Java), but deploy all my applications with Linux on the server side.

Some advice if you do make the switch:

• Keep It Simple and don't go overboard with all the "Enterprisey" Java stuff. It's fine if you're writing a banking system to last 25 years but probably overkill for most situations and will be extremely scary for newcomers. Instead stick to the more modern / simpler / more lightweight solutions. (Things like Vaadin for the UI, for example)
• Consider Scala or Clojure rather than Java as the development language. Scala is more OOP, Clojure is more functional but both are a big advance on Java/C#. Both interoperate extremely well with Java (all libraries are compatible, calling to/from Java is very easy, they run in the same process / memory space etc.) so it isn't a problem if you mix this with some development done in Java in your company.
• Get a good development environment set-up - the worst thing when making a switch is having a broken development / build system so that you don't know what is going wrong. Whether you use Eclipse or something else, make sure you have a real expert set up a best practice dev. environment so that your team members can be instantly productive / start learning without too much pain.

Answer 5

I'd like to supplement Justin Shield's answer.

Mono has matured beyond anyone's (besides Miguel) expectations. The team really needs people like your company to prove it's viability. They have to get credible traction somewhere.

Having said that, I nor anyone else would guarantee a painless transition from the .NET Framework to Mono. Think of Mono as a strict version of the .NET Framework. They implemented it based on the public API and information released to ECMA. Microsoft loves to make developers lifes easier by making things work that really shouldn't. They will probably never stop this practice. The Mono team can only know when Microsoft has done this when someone has come across an issue. Ensure the new code is CLR compliant.

There is also another solution your company can take a hard look at. IKVM. It is a Java Virtual Machine written in C#. Yes, a full JVM written on the .NET platform. Not only that, but it has a compiler to convert any Java Byte code to IL code and uses a converted version of the OpenJDK. It's another solution that needs more proving with commercial use.

Answer 6

If my employer gave me an OPPORTUNITY to work on a new project and learn a new language/framework and there was a training budget and understanding that there would be a ramp up time to become proficient in the new language, I would probably hug them.

Answer 7

Developers with a range of experience from 2 to 6 years ... How do I find something positive in moving over that will convince the other developers?

It is bizarre that a critical strategic platform decision such as this one is left to the whims of junior developers. Your senior guy needs to man up to pick the right platform for the company. In another 5 years C# very well could be on the strong decline as Win32/64 drops in importance in light of OS X and iOS uptake (don't believe this? Check the numbers and revenue graphs of AAPL). Ask your developers why they want to develop for a platform that will be dead in 10 years. Do they want to be like IBM in the 80s?

For this reason Java is the best way to go because it allows migration to the new platform (bthe desired Linux and OS X) in a cross-platform way, without other middleware such as Mono (emulation layers). C# and Java are near identical languages syntactically. .NET is just a bunch of library calls. Reference: http://www.25hoursaday.com/CsharpVsJava.html

Answer 8

My answer is assuming that you are going to move.

I'll add to @Falcon's answer:

The JVM is an amazing platform to run on. If your developers need to the power of another language (for example Scala, which supports LINQ) then they can happily use that language and directly interoperate with Java. It's much more flexible than the CLR. As @Falcon mentions, your developers can also continue developing and testing on Windows until they get more comfortable in the Linux environment. I believe that developers should also be comfortable with build, deployment, app servers etc - so I do suggest you get some training in place for that.

Definitely look at the JEE6 stack (EJB 3.0, JPA etc). It's annotation based coding will be fairly close to what C# folks do today (yes you still have to do some XML configuration, but it's not as bad as it used to be, honest). There are a bunhc of free open source application servers that will run the JEE6 code (Jboss, Glassfish, Tomcat and more). There is a particular tool called JRebel, which is a must if you are developing in this environment as it means you don't have to have the expensive stop/start cycle for your application server every time you deploy.

Alternatively if you need to do some rapid prototyping to start with then you can look at SEAM, Spring Roo or Grails, but be prepared to throw away the results afterwards.

The Java ecosystem has a library for everything. This is only a slight exaggeration, it really does have a free, open source library for just about every occasion. If there's a feature that your team misses from C# or some other library they use, there's almost certainly going to be a free, open source Java based equivalent.

Hopefully you can keep the web layer simple, based on AJAX class as opposed to any of the well meaning but flawed Java technologies (JSP, JSF, Wicket , Tapestry etc).

You can point out to your developers that the Java ecosystem is undergoing a massive renaissance at the moment, it has a really passionate community and an environment of developer freedom (you have an endless choice of languages, libraries and platforms).

Answer 9

If there's one thing more annoying than being asked to code productively in an environment you have no experience in, it's being on a team where no one has experience in the technology. The Blind Leading the Blind.

Get a Trainer/Coach/Consultant who knows the stack you're going to be moving to. Have them be part of the team and make them primarily responsible for helping your team. (Don't assign them any tasks, but ask them to rotate around and pair with the developers.) This will give your team an "old hand" to go to when they have questions about the new environment. (If you're already an agile team that does pairing, it will be easier on the uptake.)

Answer 10

A couple points I'd like to add.

Yes, as a dev, moving from .Net to Java will be a bit of a challenge.

And Yes, it does pay off for the developer, by expanding skills.

And Yes, it does in one hand pay off for the company, in that devs are more easily transitioned between projects (since language isn't a barrier)

But, there is a downside when an organization is stuck with one language. And it's the same issue as being a developer stuck in one language. When you go to purchase apps, and integrate them with your existing code, you're stuck to the stack you know and stack you work in.

You end up ignoring a great product because you don't have people trained to customize it to your needs. Or you still buy it, and do a half arsed job integrating it because you don't fully understand it. But then, you're stuck in two stacks again, with the same problems you had before.