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?

  • 10
    Bit confused; Have you decided to migrate to JAVA and need to know how to convince your team ? Or you need to know whether you should migrate to JAVA or stick to C# for this particular project. Aug 12, 2011 at 9:50
  • 11
    Tell the team to "man up". Learning new stuff is part of having a career.
    – DwB
    Aug 12, 2011 at 16:37
  • 6
    The one truism I take from the C++ FAQ is that; language choice is very rarely a technical decision, it is usually always a business decision. Either like it and learn the new language or lump it and find a business that fits your language of choice. Not being able to adapt to a new language IMO is a sign of a weak programmer (learn a new language every two years and become an expert). Aug 12, 2011 at 19:31
  • 2
    @Pankaj: Why did you put "Java" in all upper-case letters?
    – compman
    Aug 15, 2011 at 20:42

10 Answers 10


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.

  • 4
    @josten Your comment has neither... I can't figure out what you mean by that.
    – maple_shaft
    Oct 4, 2013 at 2:39

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.

  • 3
    Minor point: if you're talking about the current version of the standards, it's not called "J2EE" anymore, but "Java EE". Oh, and JSF 2.0 is already a lot better than previous versions. Aug 12, 2011 at 10:42
  • @Michael: I'm gonna correct those terms in my answer. As for JSF: I've been developing with JSF 2.0, Facelets and JBoss SEAM and it was still a pain to create custom user controls or to integrate clientside javascripts. It's probably a lot better than earlier JSF versions, I am just glad I never had to use them.
    – Falcon
    Aug 12, 2011 at 10:48
  • 1
    @Falcon, I have created controls in both yes and I concede that point, it could be easier. With JSF2 you get annotation based configuration, XHTML support, a huge selection of third party component frameworks, an easy to manipulate viewstate, control over ID's created with DOM elements, EL 2.2 and it is easier to work around third party component bugs. The only trouble I have had with rich clientside javascript API's were ones where a third party framework integrated one already into their controls and it caused compatibility issues. This has never been a showstopper for me.
    – maple_shaft
    Aug 12, 2011 at 11:28
  • 4
    I just wanted to chip in that I wouldn't waste my time learning EJBs. I haven't seen anyone use them on a new project for a long time. Maybe EJB3 is better, but you'll find it a lot easier to find examples and training for Spring and Hibernate.
    – TMN
    Aug 12, 2011 at 12:08
  • 1
    @TMN, Yes I agree, EJB is a thing of the past. I would volunteer to help dig the grave and pour concrete in just to make sure though. If people think JSF2 is over-engineered garbage, they clearly have never dealt with EJB.
    – maple_shaft
    Aug 12, 2011 at 12:11

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.

  • 2
    The developers are paid employees. I understand that one shouldn't piss off people without a reason, but if a company makes a strategic decision to use one technology throughout, then talking about "mutiny" is just childish.
    – quant_dev
    Aug 12, 2011 at 10:39
  • 2
    @Ramhound The decision to move to Java might have been made by other developers. I think the OP's team is not the only dev team in the company (that's how I read the OP's post). The argument that using a single technology stack has no value because "all languages can solve all problems"i is wrong. Theoretically, they can. In practice, we prefer modern languages to COBOL. And being able to move developers from one project to another more easily (because the tech stack is the same) is a tangible benefit for the company. Devs are often "set in their ways", and any change is often resisted.
    – quant_dev
    Aug 12, 2011 at 11:33
  • 4
    I was actually in a company who had several languages and frameworks supported internally. Ruby, Java (Spring and JavaFlow), .NET, VB6. It seriously went pear shaped having code in such a sporadic number of languages and frameworks. Knowledge silos would crop up and no-one else knew how the system worked. So consolidating all developers to using 1 language is a very valid reason on those grounds alone. The problem that I saw then, and I see now (even in my team), some devs refuse to learn a new language they see as being inferior to their current language. And it is childish. Aug 12, 2011 at 11:59
  • 2
    @Justin Shield While it is unprofessional to refuse to go from something like C# to Java I understand the fustration. I've been using both since their inception and would prefer to use Mono and fix any bugs in it's VM, than deal with the Java language. However, I would never refuse to use Java if it was deamed that was the only language. Going from C# to Java feels like you are getting so many things ripped from you. You have to show them all the OSS efforts for Java and how they can solve most of their problems. Aug 12, 2011 at 13:08
  • 1
    +1 This is the most sensible answer here. The OP is not asking whether Java is lovely to work with; it's asking about a making a complex business decision with potentially profound social, professional and technical consequences.
    – CesarGon
    Aug 15, 2011 at 23:18

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.
  • 1
    +1 and I wish 100 more. C# was easy for me to learn and Visual Studio is an amazing IDE. The things I had to learn were mostly how to use LINQ, event handling, and superior reflection, other than that I picked up the rest in a few hours. It took a while to really understand IIS and ASP.NET as well as some other frameworks. Also Vaadin looks neat, I might try it out.
    – maple_shaft
    Aug 12, 2011 at 11:52

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.


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.


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

  • It is "OS X", not "OS/X"
    – user1249
    Aug 13, 2011 at 3:50
  • heh, you say OS/X, and I think of OS/2, that dead IBM platform mentioned above.
    – nycynik
    Apr 21, 2012 at 0:55
  • In 2016, it seems like C# is still a viable resource. Xamarin has probably helped that with cross-platform native mobile development tool which writes to all mobile platforms in C#.
    – user1248
    Oct 13, 2016 at 20:29

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).

  • 3
    Can you expand on "much more flexible than the CLR" a bit more?
    – SK-logic
    Aug 12, 2011 at 10:44
  • 3
    @mikera, that comment was about support for multiple languages. JVM is significantly less flexible in this area than CLR. JVM is a single language VM by design.
    – SK-logic
    Aug 12, 2011 at 11:07
  • 2
    I want to retort your comments SK-logic (badly) but this isn't the place for what I feel will turn into a flame war. Take it to the chat.
    – maple_shaft
    Aug 12, 2011 at 11:18
  • 2
    @SK-logic: All these languages beg to differ: en.wikipedia.org/wiki/List_of_JVM_languages
    – mikera
    Aug 12, 2011 at 11:38
  • 5
    @mikera, just take a look at an awful recur in Clojure to get what I mean. All those languages are severely limited by Java limitations. JVM is semantically equivalent to a subset of CLR, so it can't ever be semantically more "flexible". By definition.
    – SK-logic
    Aug 12, 2011 at 13:07

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.)


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.