Is there any benefit by switching from C# to Java? [closed]

Question

I've been a .NET developer for about six years. In those six years, I've worked at exactly one .NET shop that followed any kind of actual design pattern or industry best practice. That realization has frustrated me where I'm at the point of considering making a switch to Java and leveraging my C# experience because the Java community seems to have a larger handle on proper software engineering than the .NET community, which seems more focused on RAD techniques and quasi-procedural code and don't want to improve at all.

For example, the average Java shop is probably using an MVC framework like Spring, Seam or venerable old Struts, is using Hibernate, is probably writing unit tests, knows how to use source control properly, and while there's the danger of the architecture astronaut is more than likely applying design patterns and following good practices like the SOLID principles.

In contrast, the average .NET shop uses untyped DataSets, writes all the code to solve a problem in event handlers of WebForms, thinks testing means loading up the built-in web server and playing with the application, if they use source control at all use something like Visual SourceSafe and think it's great, and has no idea what the single responsibility principle even means or why it's a good thing. Attempts at introducing things like ORMs, design patterns, unit testing is usually met with a blank stare or outright rejection due to not even understanding why those things are better than the debugger or writing code in an event handler of a widget - it's like talking to a brick wall.

I am aware of "ALT.NET" (I follow it myself), but I am finding an environment that knows about that, let alone follows it, and it seems to be like finding needle in a haystack, and trying to change an organization to use it has always ended badly for me, to the point where I've actually been shown the door and let go for wanting to do things better than the company had been doing before I joined.

Would there be any benefit at all to my trying to leverage C# skills and make a transition to Java? I'm running out of options trying to find a .NET shop that actually follows real software engineering concepts instead of just throwing out code, and I'm starting to think my chances of finding that kind of place will greatly increase if I'm not using a technology stack that pushes the opposite as the right way.

Answer 1

I'm inclined (having made the switch in the opposite direction) is that your mileage may vary. Both languages are very similar, but arguably C# has more language features. You won't have access to LINQ, and you'll trade one set of partially consistent APIs for another (both have inconsistencies).

Your complaints are mostly around the software development process. There is no reason why you can't architect a good .NET web application. You can use ASP.NET MVC for a good MVC framework, and NHibernate if that floats your boat. You can use NUnit for unit testing. All of these things (except NHibernate, we're using other ORM tools) are happening at the shop I work in.

Reasons for switching to Java:

• You want to learn the language and satisfy some curiosity. Nothing but good comes from playing around like this.
• The number of .NET jobs in your area is rather small, but the number of Java jobs is much larger.

Reasons not to switch:

• The average Java shop does X, and the average .NET shop doesn't. Quite frankly, there are just as many Java shops that violate good programming practice as .NET shops. Maybe more since the Java market is still bigger (for the moment).
• Microsoft sucks, and I don't want a platform controlled by one vendor. Well, Java is controlled by one vendor: Oracle (used to be Sun). You can deploy in more environments, but Oracle is as much a dictator as Microsoft.

If your chief complaint is the poor programming practices at your current job, you have a couple options:

• Try to make incremental changes to improve the situation. With every important Java library, there is a .NET equivalent. JUnit -> NUnit, Log4J -> Log4Net, Hibernate -> NHibernate, Spring -> Spring.NET, etc.
• Give up at that company and find one that does more of what you expect of good engineering practices.

Honestly, I've found that with the right attitude and some quick wins (like unit testing) that have measurable results--most companies are willing to give a new technique a shot. Especially if it saves them money. The more improvement your changes have, the more they will trust you. Just don't try to overhaul everything in one day or you will be met with serious opposition by your peers.

Answer 2

I made this switch when I moved from MS to Amazon. Actual practices aside, Eclipse doesn't hold a candle to the VS experience when it comes to development/support/debugging/out of the box magic. I default to vi most of the time because of this. You should be ready to get used to this.

But what is indeed cool about Java is the maturity / open nature in the industry around it. Java is mature enough that most of your problems usually have an alternative. If you get into trouble with GC in C# for example, you are pretty much screwed, but in the Java world you get options to manage memory off the heap (BigMemory). And the community is your typical Linux vs. MS dev community.

Finally, most of the stuff you use will be open source when you switch over to Java stack. The other day when I got stuck in hibernate with some weird issues around UserVersionType, all I had to do is to dig through hibernate code to see how they handle it. This is a MAJOR advantage compared to the closed source setups like LINQ. Make the switch, I don't think you will feel the loss of C#'s great language capabilities in light of the other advantages of Java.

But again, the more I use managed languages, the more I see myself migrate downward towards plain old C due to the amount of esoteric magic you run into in the advanced stacks. I can summarize like this: For Business development in a collaborative setup, the advanced stacks - especially Java really stands up. For quick development when you know your problem domain is limited and all you need is rapid devleopment, stay with C#. For systems development, go back to C/C++.

Caveat: I moved out of .NET world about 2 years back when all the "Foundation" code were still in development and LINQ had just been introduced. So things might have changed now.

Answer 3

I'm inclined to say "Yes", but your mileage may vary of course. I do admit rather sadly that .NET tends to foster a lack of knowledge of basic software engineering, mainly because of the influx of Visual Basic 6.0 "programmers" and the like who jumped to .NET. It's the sad reality of being a .NET developer that most of the time you're going to be working with people who haven't heard of those things, because the .NET culture doesn't exactly encourage it and the ALT.NET "movement" is still miniscule and not well known.

IMO, the bigger thing you should be looking at is what the demand is for Java in your locale. Because it's ubiquitous, Java development positions are easier to be offshored or outsourced, so before you take any plunge make sure you aren't switching to a platform that has no jobs in your area. For instance, where I live is almost 100% .NET jobs; there are extremely few Java jobs and the ones that are posted normally want several solid years of Java/Java EE experience for consideration. Even if I wanted to, it wouldn't be prudent for me to switch to Java, because I wouldn't be able to get a Java job if I did.

Answer 4

I've been exposed to (worked at, interviewed for, or was acquainted with developers from) 5 development shops since I started developing in .Net. Of those 5, one was bad, one was good, two were great, and the 5th awesome. If the shops you've worked at are really as bad as you say they are, then I'd imagine that one of the following applies:

• You're not very good at finding good shops
• development in general is bad in your area

How are you looking? (and how many shops in 6 years have you seen?) You will probably find the best opportunities through networking. Do you attend local .net meetups, or otherwise attempt to network locally? No local .net meetup? then start one. You sound like you've got the skills and attitude, maybe there is a hole you can fill if .Net talent really is that bad in your area.

I would also suggest looking for a small shop that you can change... that can't possibly be bad for your career.

Edit: Oh yeah, and put your location in your profile... you just may be contacted by an mildly offended .net developer who is part of a professional .net development shop.

Answer 5

You can almost think of Java-the-language as a subset of C#. There's not really much to learn there (aside from a few semantic differences). However, you would do well to learn about the JVM as a platform. There's a lot of good stuff going on there that has resulted in a very solid and dependable place to build software. There's no such thing as "DLL hell" on the JVM, because you really have a tremendous amount of control over the environment.

The other JVM languages, like Clojure and Scala, are also really great, and (as good as F# is) blow away the CLR competition when taken as a whole. I really think that the JVM is still a better platform than the CLR.

All that being said, a better career move might be to look at something like Python or Ruby (not the J- or Iron-varieties!) in order to get a taste of some popular dynamic languages and non-managed/VM development.

Answer 6

I completely agree with @jlnorsworthy, I've worked with good and very bad java developers over the years. I've seen the same trend in .NET. I've worked in shops which were split between java and C#. One thing holds true a good developer is a good developer programming language aside. Perhaps in your locale, the training for developers is perhaps very poor hence the poor quality. The distinction between java and C# isn't such that either developer would be greatly superior to the other. The only language which this could be true is C/C++ developer, they have deal with aspects us runtime framework developer e.g. java and .net would even realise exist, such as real memory management. We runtime developers don't realise how hard it used to be writing a simple app. I've done java and C# commercially, there mostly the same simple holding your hand modern 3GL.

"Struts, is using Hibernate, is probably writing unit tests, knows how to use source control properly" wow. I'm working for a big .NET shop with about 500+ developers across numerous business units. We definitely follow patterns, using TFS and I've seen approaches I never thought possible with .NET. I'll give ideal how structured the environment I work in. Everything runs autmotically through build servers, we don't deploy anything manually, to dev, test and production. Even a shared framework in pulled to our local machines via powershell scripts. All projects are MVP or MVC with unit tests, and shared database framework project. Actually we can't even checkin if a unit test fails, policy of TFS applied.

Answer 7

In New York it certainly seems like it is much easier to find Java shops with source control, unit testing, and some process than it is to find .NET shops. There are some .NET shops which are like this, but many more which reading the ad (and even inquiring) are the just get it done yesterday no matter what, without much thought given to keeping the code maintainable.

Also many of the startups seem to use Java as opposed to .NET (probably licensing costs) although there is one notable exception I have seen where they use .NET and are proud of it. And based on their ads/what people say, it looks like a great place to work. The problem is what to do for your next job....

Additionally many of the PHP/Ruby/Python/Perl shops are willing to accept Java experience (per the job ads). Since in New York recruiters/HR are often between you and the job (unless you have a great network) lack of Java/PHP/Ruby/Python/perl experience gets your resume tossed... On the West coast this would seem not to matter as much since many jobs are phrased x years object oriented programming experience.