Why Java should focus on the standards
(Note : This post was written before the fallout over the Spring licensing issues which does reflect on the content of the post. However, I didn’t want to get drawn into that issue too much and dilute the point of this article. I have added some additional thoughts here)
In general, there are advantages to choice, but the whole 31 flavors of java development is mostly harmful. People are forgetting about flavour 32 which is to drop java and go use something where the vast majority of developers use the same tools, libraries, frameworks and products. Java becomes massively unproductive when you spend weeks or months examining frameworks and get stuck in analysis paralysis, and then grudgingly move on waiting for the gotcha moment where you realize you chose the wrong one.
Ice cream, which is the oft-used analogy for choice, is something I eat in 5 minutes and then move on with my day. Picking a java framework is something that you will have to live with for the rest of the project, possibly the rest of your career, and will impact every single employee and customer that comes through your door. When a .NET shop gets a new project I doubt the issue of spending time comparing and choosing which framework to use even comes up. Given the number of successes and the growth of .NET it doesn’t appear that this lack of choice has hurt the platform. It did however boost third party component support since all vendors were developing for the same Winforms or ASP.net platforms.
Most democratic countries in the world have only two or three major parties from which to elect President/Prime Minister/Grand Poo Bah, but imagine if there were five or six equally supported parties all of which had sizeable support from the electorate. The result would be an elected official with around 20% of the voters’ support. In reality, we tend to gravitate towards two or three mainstream contenders (Democrat/Republican, Conservative/Labour), although there are a few secondary parties also (Independents, Green and Liberal Democrats). The same too is true of java frameworks. For the most part, in each area, there are two major contenders with a few also-rans. Spring and EJB come to mind as the two most prominent frameworks about which the debates rage. In terms of JPA implementations, Toplink and Hibernate are two popular ones with iBatis and OpenJPA as alternatives.
If we consider a comparison of development platforms you might have .NET on one side and java on the other except there is no single java platform. The java platform consists of a number of sub-platforms that make up the whole. As a result .NET only has to be better than the strongest java sub-platform to appear as a better alternative. “We’re not the best, but we have several ways of doing things almost as good as our rival” isn’t a winning slogan.
How many times have you heard it said that you should choose the right tool for the job regarding frameworks? Can you imagine starting work on a building site, being told to cut a piece of wood, spending 20 minutes looking at the wood and your collection of saws before choosing the most appropriate tool for the job? This is not something that you hear often in the .NET forums. Is it because the .NET stack and developers are so superior that they can deliver anything with the stack?. The truth is that both the framework and developers are good enough to deliver 90% of applications written today. Why doesn’t java have a framework that can deliver the features needed by 90% of applications? It does, in fact the problem is that it has too many. There are a number of frameworks which are capable of delivering the goods but they have diametrical and incompatible interfaces.
One other area where the number of java choices is harmful is regarding employment, from both the employer and employee perspective. If you are looking for a programmer who has at least 12 months experience developing with ASP.net and Oracle, you pretty much have a good idea what that programmer has done for that 12 months. Compare that to a programmer with 12 months java and oracle experience and you have no idea. Let’s narrow it down to JSF and Oracle, and we still have a wide range of options as far as what kind of development they have done. Did they use Spring, EJB, Seam, hibernate, JPA or JDBC? The job ad for the .NET developer mainly asks for ASP.net and Oracle, while the java ad is filled with buzzwords and TLAs to cover all the bases. That might not seem important but it is when someone vetting candidates turns you down because you only have Hibernate, Toplink and iBatis but no JPA experience.
“If you tolerate everything, you stand for nothing” springs to mind with regards to java. We let everything come under java umbrella and fail to define what it means to develop using java. Saying that you are a java developer is much more vague than being a php, ruby, or c# developer. If java fails to define itself, then their competitors will.
Following the standards
The solution to these problems lies in defining and following standards. In part, we need to realign our thinking on ‘standards’. Typically, we think of standards in terms of a standard set of implementations that we must use. However, we need to start thinking about standards as a common way to interface with the vast array of libraries java offers. If we cannot decide on implementation, let us at least decide on an interface for it. Using JPA as an example, originally we had different ORM libraries, each with a different way of defining model mappings until the JPA spec defined a standard interface for these libraries. The libraries themselves didn’t change much if at all, they just chose to implement the standard interface. As a result, if you are familiar with one JPA implementation, you found you could transfer 90%+ of your knowledge and code to use other JPA implementations. IDEs suddenly didn’t have to worry about letting you reverse engineer or generate mapping files for hibernate, Toplink and/or iBatis. Suddenly, they just had to be JPA aware and you got IDE tooling for all JPA implementations in one go. I’d also put forth that employers looking for a java developer having JPA with hibernate skills will feel easier about hiring someone with JPA with Toplink skills since if they already know JPA then they already have most of the requirements. Each implementation usually offered ways around quirks in the standards by using proprietary alternatives until those quirks in the standards can be worked out. At that point, the proprietary method will still be available so old code doesn’t break, and the standard will give developers a standardized method to use. By implementing and using standards we get a better idea of the gaps that they present and we create a feedback loop that keeps improving the standards, or identifying the need for new standards.
Following a standard in fact gives you more choice. Again, taking JPA for example we have different implementations to choose from, each with varying degrees of support in the java community. Standards can also give you choice because it is a great equalizer since it allows newcomers to enter the marketplace. Joe Smith could release a JPA implementation tomorrow and it could compete with existing JPA implementations on an equal footing since it requires no code changes to try out this new library to see how it performs. Without the JPA standard, Joe Smith would also probably not have started a new ORM library knowing he had to compete with the incredible success of the existing tools and wrestle market share from them. By having users that follow a particular standard, if you implement that standard, it can gain you instant marketshare since developers favor the interface over the implementation. If developers were still using the non-standard hibernate interface, they would not be able to easily switch implementations and would still be locked into the proprietary interface. This also demonstrates another benefit of standards. Buyers remorse for a particular framework or library can be overcome by switching to an alternative with little to no code changes as long as you code to standards based interfaces. This makes the decision making stage easier since rather than picking specific frameworks, we can pick the standards we choose to develop with. If you go with JSF and JPA, you can get started writing code. Later on, if you decide to switch from one JSF or JPA implementation to another, then you can do so.
For many, the standards are good and getting better. Others disagree, or have their own implementation preferences or just a rebellious rejection of the conventional. In some cases, this is a valid argument, but the answer lies in improving the standards instead of abandoning them altogether. Currently, we have the EJB standard as a component framework. Older versions of this proved unpopular and gave way to pojo based frameworks such as Spring which expanded the concepts regarding AOP and dependency injection. For many this has turned into an either/or situation forcing users to choose between standard EJB 3, or Spring which has divided the community somewhat. The right course of action is to define a new standard which encapsulates the functionality missing from existing standards.
When choosing technology frameworks, in general, the further up a stack a decision is, the more items it will affect below it. Also, the further down the stack (closer to the client) a technology is, the less likely it is to affect the items above it. This demonstrates the need to focus on the top of the stack where the most important decisions are made first. Many people are stuck on the Spring/EJB choice and being able to try both without coding to a non-standard interface would deflate the importance of this decision. Also, it should be pointed out that the lower you go down the stack, the less likely you are to be able to standardize aspects of it. JSF is a standard, but it is also one of many view technologies that have little in common with each other and would not be able to work under a single standard. We cannot for example expect to see a standard which can be implementated by both JSF and Wicket.
Branding the Java platform
Java needs a stronger branding in terms of defining what being a java developer entails. If you remember back to when Sun was polling the community on what kinds of profiles should make up the JEE 6 platform, the usual dysfunctions crept in. We had to have EJB 3.1 (lite and non-lite) as well as the kitchen sink thrown in for good measure. Some worried that Sun was imposing their choices on developers, which is the whole point! Microsoft doesn’t take the Castle Project’s active record implementation or nHibernate and make it a part of the .NET framework for obvious reason. If people choose to use those outside of the main framework, they are free to do so. If java developers want to use Hibernate or their own ORM tool, they may do so, but it should remain outside of the standard java stack which is reserved for standards based libraries. The brands should be as granular as possible. Sun has already experienced difficulties with this regarding the Java Standard and Enterprise edition branding. This simple definition soon sprouted more alternative definitions and expanded to include web applications, EJBs, messaging, JavaMail, WebServices, SOA, JSF, JSP, transaction and database management, essentially the kitchen sink. Let’s not make the same mistake again.
Treat Standards Like Projects
It’s been a couple of years since the JSF spec was released and only now are we seeing the drafts for JSF 2.0. This is despite the fact that there have been a number of problems with the standard since day one. We need to start treating specs like projects builds and producing interim patches to address problems that only become apparent once it has been released. Obviously some of the larger feature changes in the spec will need to wait until the next ‘major revision’ of the spec, but some of the smaller problems should be addressed sooner.
2 thoughts on “Why Java should focus on the standards”
Comments are closed.
So you think project like log4j should be closed and deprecated, because it doesnt fallow the standard that was created because of this project? (jdk logging doesnt have debug level, they called something else just to show whos the boss).
Many standards are broken(like JSF) and the reason is that it was standard first, before people started using it, so to use JSF you need some sub-projects that make it usable (Faclets, Seam).
When you create standard it should be after some cool technology was used for longer period of time and is realy needed (like Joda Time that will soon be a standard). JPA is great because all the bad ideas were found and fixed when people were using Hibernate.
I think we have too much standards in Java world. Standards should be like JPA and not JSF.
Another good example is TestNG and JUnit, JUnit is the standard, but TestNG has some cool features. TestNG is little bit different (assertEquals has revearsed params). It is almost the same thing as JUnit and I see no reason why not to use it.
I also think that want works is what one should use (it is better if it a standard, but if it is not, I do not care).
But AFAIK JUnit is not a standard, it has the same status as TestNG, it just has a broader user base, maybe you think TestNG is better, but the majority uses JUnit. JUnit is a de-facto standard (like Spring is, or Hibernate was), it is standard because everybody uses it, and those are the best standards (Of course you may argue that TestNG is better, but I guess so far the community does not agree with you).
I am certified in .NET and I really think it is a great platform (it avoided many of the pitfalls Java fell in, for example, the DateTime API in .NET is much easier to use). But I do not really think that Microsoft is that good setting standard way to work, when I started with .NET I felt really lost, I .NET 1.0 there was a default ugly not scalable and not maintainable way to do things, and not a lot of architectural guidance. I think Java should not try to emulate .NET (that is what Sun Studio Creator tried and failed miserably). I think Java should take a look at the way NextStep WebObjects did things, and try to make the next JEE version what WebObjects 6.0 could have been.