I've been developing software for over 15 years working in Delphi and now Java. This site is a home for my open source projects, writings, articles and tutorials mainly focusing on Java and Java EE. Andy is a DZone MVB and is not an employee of DZone and has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Why Java should focus on the standards

10.06.2008
| 5438 views |
  • submit to reddit

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.

 

(Reposted From : http://www.andygibson.net/blog/index.php/2008/09/30/why-java-focus-on-the-standards/)

Published at DZone with permission of Andy Gibson, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Osvaldo Doederlein replied on Mon, 2008/10/06 - 12:43pm

Let me take on your election metaphor. In my country (Brazil), despite a solid democracy (althoug much less mature than say the US), there are dozens of political parties, and even counting only major parties that stand chance in a presidential election, there's at least five or six choices (not considering a minor party leading a alliance with larger parties). But this doesn't result in presidents (or governors, or mayors of major cities) being elected with 20% of votes; to handle this situation there are second-turn elections, to make sure that the elected candidate is chosen by at least 50%+1 of all voters.

When it comes to Java frameworks, the "second-turn election" is usually the popularity of each framework and its level of support by the whole toolchain and ecosystem. For example, for persistence, I could perhaps evaluate Hibernate and iBatis and like both of them equally (some technical and productivity advantages here, some there). But the "second-turn election" favors Hibernate massively:

- Hibernate has great IDE support from all major IDEs, this gives me high productivity: visual editors for configuration, "wizard" generation of skeleton code, integration with other tools like DBMS support, etc.
- Hibernate is supported by application server vendors.
- Hibernate is very popular, I can hire new coders that already know it (without a premium price).
- Hibernate is endorsed by my clients - read: "large corps with tight-ass technology endorsement rules" - I can talk to their IT people and say, "we're going to use Hibernate in this project", and they won't create a problem (likely, they probably already have production apps built with Hibernate, so that's in the "safe" category).

If you use these "second turn" rules, it's very easy to choose your Java frameworks. And the resulting choice - just like in elections - is usually at least very good, if not ideal; because frameworks must have some merit to become extremely popular and well-supported, against the fierce competition that exists in the Java ecosystem. And you're not in worse situation than in the .NET side, where choice is also easy but the risk of that single choice being less-than-ideal exists too. Microsoft is not brilliant in 100% of their framework designs (far from that indeed). The existence of a single choice is not a guarantee of its high quality in all aspects (performance, productivity, maintainability, openness, etc.). Ignoring this simple fact leads to many false assumptions that apparently favor .NET over Java.

The ideology of following a standard is also a good bet, if the production of those standards is competent. I think this to be generally true for the Java standards (and my modest participation in the JCP is an endorsement of this belief). There are some major blunders, but they are usually "corrected" by the community - e.g., Entity Beans being eventually replaced by JPA, or java.util.logging being ignored by all sane developers, who continue preferring Log4J. The good thing is that the "second turn" strategy even protectes you from bad standards. Entity Beans, for example, never became very popular - and due to its major flaws, it wouldn't pass in the "first turn election" of any good architect. In my whole carreer of enterprise software development with Java (and I use Java since 1.0beta and J2EE stuff since JSP 1.0beta), I participated of a single project using Entity Beans, and this is because my client mandated the use of this technology... but, to finish the elections metaphors, this is dictatorship, not democracy. World != perfect. ;-)

Yaozong Zhu replied on Tue, 2008/10/07 - 4:05am

I 100% agree with author. The massive options in Java community sometimes make developers (particularly for freshers) so difficult to follow. I like the concept of JPA which serves the standard interface for persistence. But "standard" need evolve quickly. I allways have to use native Hibernate together with JPA, as JPA 1.0 isn't comprehensive enough. I am waiting for the new JPA for a long time.

Steve Hicks replied on Tue, 2008/10/07 - 4:14am

Actually it is a strength of Java that there are good alternatives to standards which can be used when the standards are naff (e.g. entity beans).

 The important thing (which seems to be the case with JPA) is to use the best of alternative frameworks into newer versions of standards. I think a similar thing is happening with Web Beans (from Seam).

 I hope that JEE6 will allow out of container testing with a similar level as I can now get with Spring (where the current changes to the release tags shows the danger of not using standards)

 My current approach is to use standards as much as possible but not ignoring any alternatives if there are significantly better alternatives for my problem domain

Michael Hodgins replied on Tue, 2008/10/07 - 8:21am

The author is right. I hate to say this but Java is the reason I use PHP.

David Lee replied on Tue, 2008/10/07 - 9:15am

Excellent article and I couldn't agree more with the author.  Every single java shop I've worked at has wasted countless hours choosing tools and frameworks and the final decisions have always been drastically different between shops.

Andy Leung replied on Tue, 2008/10/07 - 10:40am

Thanks for the great article.  I have a couple questions of what the author mentioned though.

Just a quick question of how many .NET framework out there? I have no idea.  But I am sure that there are many .NET developers using different types of framework.  For example, .NET doesn't have built-in MVC, you may use VB like, which is like JSF, style but it is not for large applications.

Another question is, how do you know normally .NET developers are using ASP.NET for development? All my friends are using C#.NET and I see more C#.NET jobs on the market.

My last question is simple.  I wonder if it is more an IDE-related issue instead of standard?  For example, JSF + JPA + JEE5 container, isn't this already standard?  Before Netbeans 6.1 (NB) came out, there were not many IDEs that really did the job such as generating lots of smart code and server integration.  I can see that NB community is growing very fast after NB 6.1 came out.  When developers look for fast development here, they are using purely Visual JSF + JPA + Glassfish and the easiest thing to learn is to follow their tutorials with screen shots, what can be easier?!  I don't know about others, speaking of myself, I immediately dumped Spring, Hiberate and Struts!  I give at least 9/10 of configuring JSF apps in NB than Spring, Hibernate and Struts even though they do have certain level of integration.

It looks to me that developers pick up the easiest thing for their job because time is tight and they have to do a lot of preparations before using these tools.

So I think it's more like a tool issue than the standard and by the way, Spring, Hibernate and Struts are all following most, if not all, Java standard.

Robert Sanders replied on Tue, 2008/10/07 - 11:10am

My take: Java standards have a problem in that the standards setting is a) too slow (at least for beta/prototype releases) and b) much too focused on the 'needs' of the various vendors.  With .NET MS controls the whole show, and while they keep it focused on their needs, at least they don't tend to fill the "standard" with holes just so that someone can fill it with a propriety extension (as the majority of what they do is proprietary anyway).  Just my two cents.

Jeroen Wenting replied on Wed, 2008/10/08 - 12:20am

Java iz Ded!!!!!

 It's been a while, I've been missing the Java dissing that was so common everywhere up until recently.

Harald Krake replied on Wed, 2008/10/08 - 3:40am

Imho it's not a matter of standards in general. It's a matter of how standards
are designed. Java frameworks/standards are usually open source and
designed with a rather "academic" approach, whereas proprietary frameworks
are more business oriented and targeted for the 90%-case. They are focused on
productivity rather than technical elegance.
Let's look at Swing as an example: in every serious (desktop) enterprise application
you have to limit the number of characters in textfields according to the
database model. Instead of providing a simple property (let's call it "maxColumns"),
Swing forces you to create your own home-grown Document model.
JTable is another example. Elegantly designed but in real life absolutely unusable
without massive extensions. Take the Preferences API. Where is the database backing store?
You don't want to store the preferences in the windows registry, don't you?
There are hundreds if not even thousands of such loose ends.
As a result, every software company comes up with its own "framework" implementing
what is missing from the standards.
Instead of introducing even more abstraction levels, the Java community should
better focus on getting things done.

My 2 cents,

Harald

Jeroen Wenting replied on Thu, 2008/10/09 - 4:07am

a far easier way in Swing to force input limitations is to implement a listener on the input box and have that do the validation.
Embed the whole thing as a compound component with the input limit as a constructor parameter and you're set.

Would have been a good idea maybe to have that as standard, but it's easy to create.

JTable is quite usable, but is indeed complex because of its massive flexibility. That's the price you pay for having generic components that are powerful.

Ronald Miura replied on Fri, 2008/10/10 - 10:08am

Microsoft doesn't have standards, they have products. It's a very different market than Java's, so I don't think direct comparisons apply. They don't have the overhead of creating a comitee, just for formulate an imaginary spec for vendors to implement. They just make a product, and make it be installed to your machine automatically (and, if you are a developer, just include the new product into the SDK package, so you'd always download it).

But, as far as the debate on standard versus choice goes, as Osvaldo Doederlain said, It's a dictatorship versus democracy issue.

When you choose Microsoft, you choose to have a dictator who decides what you have to do. This does have advantages, like a single, coherent (most of the time) vision of how things should be. But once you are there, you don't have choice but to follow their lead, that being the best or the worst way.

The same way goes with the Ruby on Rails camp. As they say, they have a 'benevolent dictator'. At least they admit it. And the same limitations apply, the only difference is that if your problem doesn't fit their technology, you are just invited to leave ('if it doesn't fit your needs, don't use it'), which is kind of logically correct, but then you are back to zero, and have to search for something else, completely different alternative.

In Java, you have a kind of democracy, where you must choose what to do, as nobody will give you a definitive answer. Which is far from perfect, but at least you have freedom, and you can take responsibility of your own choices, instead of just accepting someone else's.

I tend to favor freedom. Standards are important? Of course! But standards are most useful and easy to 'get right' when they are minimal. Standardize basic plugs and protocols, but don't standardize the products. Standard energy and TV input plugs is good, but making XBox a standard isn't (not that XBox isn't a nice platform, but what would happen to Wii's innovation?).

Well, I don't think you would want to live in Cuba, China, or the old USSR, as you certainly value freedom, specially if you are from the USA (since they even destroy entire countries in the name of freedom). Why you'd want to live a dictatorship in your professional choices?

Jeroen Wenting replied on Mon, 2008/10/13 - 1:23am

Microsoft does in fact have standards...

C# is an ECMA standard, with Microsoft as its steward (and at the moment AFAIK only steward).
Similarly the Office 2007 XML document format is an ISO (I think) approved standard.
Microsoft is an important member of the W3C standards commitees for CSS and HTML among others.
etc. etc. etc.

Ronald Miura replied on Mon, 2008/10/13 - 9:14am

Microsoft doesn't follow standards, they standardize its own products.

The OpenXML format (the MS-Office 2007 XML-based document format) was approved by ISO under a completely absurd process (like, discussing a list of 3000+ technical issues in 5 days!), and includes competely absurd definitions (for example, the standard includes many wrong definitions for mathematical functions, for BUG-compatibility to previous versions of MS-Office)!

And it's almost funny to put CSS/HTML standards and Microsoft in the same phrase. :)

Maybe IE8 will make me take my words back, and I'd be really happy if it did, but I won't hold my breath while waiting...

Harald Krake replied on Mon, 2008/10/13 - 11:07am

Standards are more or less temporary. EJB 1, 2, 3, ... next? ;) That's why enterprise applications not being permanently refactored become hopelessly outdated after a couple of years and will be rewritten from scratch, in whatsoever language for whatsoever platform implementing whatsoever "standards". Productivity is a major concern and will always influence the decision process whether to use Java with frameworks x,y,z or Rails or ... or .... or -- go with Mordor. Middle-earth might be the land of the open source minded, nevertheless it is in competition! ;)

Sure, you can extend the standard Java classes to keep up with the features provided elsewhere, but why is almost every software company seriously developing Java apps forced to create its own underwaterhandcarved Makejavausableframework? Java "Enterprise" Edition in fact is just a JDK-XXL. "Enterprise", however, should cover the 99%-case (or at least 90% ;)).

Just two screenshots to show what I mean. One is from Mordor and the other taken from Netbeans with -- you guessed it -- another "enterprise" framework:

 

 

Should Java focus on standards?
Sure, but don't forget the real-world requirements!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.