Background

Recently we’ve just integrated a new Dev, Cert, Production environment in which we use:

1. Java
2. Spring
3. Maven
4. Eclipse

Using Jetty for development and Tomcat for deployment.  In hindsight that statement is a dead giveaway that problems are forthcoming.  Since usually it’s a good idea to use the same kind of environment for Dev, Cert and Prod.

Previous Jetty Pluggin Configuration:

Here is the plugin configuration we used for a Jetty (SSL only) configuration inside of our pom.xml/project/build/plugins:

	<plugin>
		<groupId>org.mortbay.jetty</groupId>
		<artifactId>maven-jetty-plugin</artifactId>
		<configuration>
			<contextPath>/</contextPath>
			<connectors>
	        		<connector implementation="org.mortbay.jetty.security.SslSocketConnector">
	                		<port>8002</port>
					<maxIdleTime>60000</maxIdleTime>
					<keystore>${project.build.directory}/secure.server/WEB-INF/classes/jetty-ssl.keystore</keystore>
					<password>jetty6</password>
					<keyPassword>jetty6</keyPassword>
				</connector>
			</connectors>
		</configuration>
	</plugin>

Goal – Overridden Resources

We develop in as modular fashion as possible so some projects provide “Default configurations” that are expected to be overriden by consuming projects.  Things such as properties files and spring configurations.

Example:

Project A has settings.properties in the resulting jar classes directory and
Project B also has an override version of settings.properties in it’s resulting classes directory.

This is an integral part of our deployment process allowing us to keep cert and prod passwords out of the main project where developers will see.

Symptoms

We found that during development sometimes our override settings would be ignored and the “default configuration” would be used.  To be clear:

Project A\classes has:
\settings.properties
\some classes and packages

Project B\classes has:
\settings.properties
\some other classes and packages

When we tried to access settings.properties in the classpath spring at runtime, sometimes the Project A version was used and sometimes the Project B version was used.

Example spring Include:

	<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
		<property name="location" value="classpath:settings.properties" />
	</bean>
	<bean id="testStringValue" class="java.lang.String">
		<constructor-arg index="0" value="${test.string.value}" />
	</bean>

Example properties file:

	test.string.value=String Value 1

Found Issue

After lots of troubleshooting, we ruled out both Spring and Maven as the culprit.  Using test classes in Maven to run the SAME test code worked perfectly (used Project B version), while for some reason using “mvn jetty:run” to have the same code invoked FAILED as stated above.

We therefore found that Jetty was actually the issue, likely boiling down to one of these things:

• the out of the box configuration
• a shortcoming in Jetty
• or the Maven Jetty pluggin

Resolution

We switched to tomcat development/testing environment by using “mvn tomcat:run” to test and this configuration instead: (Cofigured to be SSL only)

	<plugin>
		<groupId>org.codehaus.mojo</groupId>
		<artifactId>tomcat-maven-plugin</artifactId>
			<version>1.1</version>
		<configuration>
			<path>/</path>
			<httpsPort>8443</httpsPort>
			<port>0</port>
			<keystoreFile>${project.build.directory}/secure.server/WEB-INF/classes/jetty-ssl.keystore</keystoreFile>
			<keystorePass>jetty6</keystorePass>
		</configuration>
	</plugin>

I have been asked this question numerous times and, since I have a unique perspective to offer on the topic, I figured I’d write a post about it.

Background

First a little background.  These opinions are coming from someone who regularly develops large applications in both Java and .Net. and is certified by both Microsoft and Sun with programming certifications:

• Sun Certified Java Programmer for Java 1.5
• Microsoft Certified Technology Specialist: .Net Framework 2.0: Web Applications
• Microsoft Certified Technology Specialist: .Net Framework 2.0: Windows Applications
• Microsoft Certified Technology Specialist: .Net Framework 2.0: Distributed Applications

Yes the Java and Microsoft tests are quite brainwashing

I have been programming for a long time and have, like many career developers, developed in at least 20+ different mainstream languages.

That being said, I still lead a normal life and do NOT have star-wars pajamas.

Java or .Net

Short answer: I love both.  Both can do the same tasks yet both do them quite differently.

With each you will notice a flavor that is unmistakable, and as such you will tend to use them for different things should you have the choice.  This article is relevant to Web Development, Desktop Development, Database Development etc.  Both platforms are capable of the same things now-days and the outcome is the same across all of these areas.

About: Java

Feel

Java has a more open and unrestricted feel. If you want something you don’t see, you can make it yourself or, chances are, someone has already written it and has most likely shared the source code for you.  You are allowed to have access to the underlying platforms and if there is a bug or feature you don’t understand you are free to investigate it yourself.

Development Environment

In Java, getting started with your Development Environment (program used to write code) is generally harder, yet getting a new server is cheaper.  In the event that you wish your application to run on a completely different operating system, chances are you can do it without rewriting everything.

For a developer, the Integrated Development Environment (IDE) is your window into the world of code.  Without it you would be writing every line of code by hand which without these tools would be between 5 and 50 times the work.  With Java, in order to get up and running, you need to set up this tool, the prerequisites and the 50 plugins that you need yourself.  The process takes more mental effort and has a lot of points where something can go wrong.  Keep in mind though, this generally only happens once per machine.   It’s just really annoying when you have to do it on a new machine.

That being said, I find that the Java IDEs tend to be much more helpful than their .Net counterpart.  They tend to offer more “shortcuts” for you to get more work done with less time.  Once you get used to Eclipse (the Primary industry standard Java IDE), you can code up a storm in no time flat.  Again, imagine you thought of a new “shortcut” feature, you could code it yourself and have it in the official distribution of Eclipse in a matter of months for everyone on the planet to use.

Price

In comes one of the primary differentiators in the market.  To start up with Java, you can theoretically do it without paying ANY licensing costs.  This one line bugs a lot of people.

Am I saying Java is a cheaper platform than .Net to an organization?  No, but you can start it up for darn near free.

When choosing a platform for an organization there are a myriad of points to take into account.  Not the least of which is available local help.  If there are no Java developers in your area yet you have plenty of .Net developers on tap I’d say that’s a pretty big part of the equation.  If Java developers are $X/hr and .Net developers are 1/2 $X/hr I’d also say that’s a pretty big part of the equation.

No matter what anyone says, given all other factors being equal, Java is cheaper to run, straight from the bank account.

About: .Net (usually C#.Net)

(Mainstream .Net, not mono or other open source initiatives)

Feel

The feeling of .Net is a more rapid development feel.  You get a lot more of a “just get it done” approach because developers have VERY LITTLE control over the underlying framework and are often penalized for re-inventing something that Microsoft provides a library for. Whether or not the library is good or crap.  Nowadays the Microsoft libraries, tools and practices are PRETTY DARNED GOOD.  I know this may shock a lot of people coming from the Java world.  It didn’t used to be this way.  In the past Microsoft’s development platforms have tended to kind-of suck.  But these aren’t the VB6 days or the .Net 1.1 days.  We’re on .Net 3.5+ and since 2.0 they’ve been cooking with gas.

Development Environment

Insert CD and press Go.  That’s the process with Microsoft’s Visual Studio .Net (VS.Net) development environment.  You point and click and the work is done for you.  Everything just works and there is a lot less to worry about configuring or understanding for that matter.  This has been a staple for Microsoft from the start, however with the changes in creating a platform like .Net to give such massive capabilities, there is one new caveat.  Sometimes, when things go wrong… they go wrong they go HORRIBLY wrong.  Given the closed nature of the platform you are dealing with more “black boxes” and that mean harder to fix.  Therefore an experienced superstar developer can chase his/her tail for 5 hrs to find a setting required to fix a problem and only at the end of 5 hrs of searching will they find it or find that you CANT do it.

Microsoft has been learning from java and has incorporated more “shortcuts”, however with the longer time to market I still find Java IDE’s come out ahead there consistently.  That will likely change in the next couple of years.

VS.Net also offers some benefits over Eclipse in terms of Integration.  Being that both IDEs are extensible, they both have a laundry list of capabilities, however VS.Net is developed by the same company that developed the database server, the integration server, web server, the source control server and so on. More things just work and also there are a lot more out of the box visual screens to configure these pieces with your code.

Price

Well, here’s the kicker.  In order to use that press and go environment, at the time of writing this article it will cost you:

• $750 per developer (for VS.Net 2010 pro)  or $1k-$2k with a MSDN subscription.  (MSDN is the “in club” for Microsoft that offers upgrades, software and developer support tools.
• $750 per server (Windows 2008 R2) for the first 5 users, then $170 per additional 5 users
• $2400 per database server (in addition to Windows 2008 license) for the first 10 users, additional users extra.

This list does not include things like anti-virus protection or email servers etc.  This is JUST to get you up and running for development only.  Being a “Microsoft shop” has its advantages and disadvantages and the full costs there are out of the scope of this article, but believe me it’s not cheap to do “legally” even if you don’t want the full feature-set.

I personally find that developers that use .Net often simply use pirated versions that they get from work or friends and have noticed this as a trend in colleges too.  Often students want to learn the real thing and do not want the crippled version made available to them by their university.  Both of these are technically illegal.  Most developers I have come into contact with believe that Microsoft recognizes that the extremely high costs of the platform puts it WELL out of reach of the very developers they need to use their products.  In recognizing that people seem to think they don’t mind.

Personally I find it scary to have $70k of illegal software loaded on a drive for someone to find.  That’s just me though.

Verdict

As a mixed developer (remember the background), I routinely use both platforms on a regular basis and here is why:

Price

For projects in my own business, 9 times out of 10 I chose Java due to the low cost of getting a production rackspace VM, throwing up tomcat, loading my code and being done.

When you multiply the licensing costs by three for development, certification and production environments, for a small business that cost is crippling.  So since I’m the one paying for these licenses AND I don’t have to pay 80k/yr for a sys-admin (I can do it myself), I chose Java for most of MY OWN projects.

Also, there’s more scriptability with Java since you can use Linux so creating new environments tends to be much more of a breeze no need for point and click.

Capability

In my opinion, a seasoned developer in either platform (C# is the predominant .Net language) can accomplish the same tasks and provide the same benefits of robust code, scalability and maintenance friendly.

So ignoring “mistakes” made by inexperienced developers, there is still one thing I have noticed that is very different between the platforms.

Sales???

In my experience (as a consultant so keep that in mind) .Net work seems to pay more and to do it consistently. Many corporations that aren’t in the business of releasing software and instead develop it in-house for themselves seem to appreciate the “no brainer” approach of relying on Microsoft’s suggestions rather than having to explain to their SVP why these technical details are better than those technical details. They can just say, It’s Microsoft’s standard. End of story, now budget me $200k more.

But again keep in mind it depends on what part of the world you are in, what type of budget the companies you plan on doing work for have etc etc etc.

Here’s a special tidbit though:
From a marketing standpoint, what would you prefer to look for in a customer that you have not met: 1) A customer who has possibly demonstrated his/her willingness to chose the cheaper route 2) One who has possibly demonstrated his/her willingness to pay more for the “right thing”? (keep in mind: If you don’t know better, you might rely on an “authority” like Microsoft)

I think an argument is there to be made that a “Microsoft shop” may be in some cases a more desired client because they TEND to pick less at costs and SEEM more concerned with the outcome and final ROI.  Also they tend to be more willing to give you more of the technical burden because in general they don’t understand it.  All Java/.Net clients do not fit these trends however if you were to pick a customer base, you would need to consider this angle.

There area lot of arguments that can be made for and against the platforms, but these are the reasons I choose them and use BOTH regularly.

~JC