Articles


Java Standards Redux – Spring Licensing Fallout

In this post I talked about how the Java standards are important to ensuring java has a long and fruitful life. This post references Spring as an example but was written before the fallout from the Spring licensing issues. This fallout tends to back up the argument that standards are important, although since there were no standards at the time for Spring to follow, it is not a totally valid position.
Over the years, many people have been knocked for claiming that Spring is a proprietary framework. How can it be when it is open source would often be the argument. Proprietary in its literal sense means that it has one owner or controller which is true for Spring for the most part. A less formal definition when discussing programming, Java in particular, is that it does not follow any open standards. Spring broke a lot of new ground which in many cases, meant that there were no standards or only bad standards to follow. However, a number of developers also bought into using other Spring features like the Templates to aid them in their development.
Now that Spring has penetrated developers code to a large degree, vendor lock in was in place for many companies with large spring based projects and Rod and Co turned off the free beer once everyone was hooked. Again, it’s their business, their platform, and they can do with it as they like.
However, if the Java platform had a set of good standards for defining framework functions, then nobody would seriously bother with a non-standard framework, and nobody would be able to shut off the tap because they could be replaced in an instant by an alternative implementation of the standard. Again, this reinforces the need for good standards (like EJB3.1 appears to be) and also for timely updates to the standards.

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. Read More »

Is Spring between the devil and the EJB?

Reading this post on Javalobby prompted me to go and dust off a post I wrote a while ago but hadn?t published regarding Spring and the revitalized EJB standard. At the time I was fired up by this post by Rod Johnson which seemed to be a large helping of FUD and insults. Nonsense such as suggesting that because some people were using app servers and some weren?t the age of the app server was over, like suggesting that because I want a shovel to dig a hole, we no longer need backhoes. This was interspersed with some irrelevant quotes from Gartner made to look like evidence and malicious comments about EJBs and their users. It seemed like the Spring folks were chomping at the bit to pronounce EJB dead when in fact, as evidenced by some recent posts, it is very much alive. In hindsight, it seems the Spring guys were trying to lay some marketing groundwork prior to releasing their own OSGI application server.

This brings me to this latest post, one of a number of recent posts which sings the praises of EJBs and in this case asks the Spring developer “why not?”. It’s almost like the question nobody asks because the presumption is that the answer is obvious. It also touches on the issue of Spring and EJB developers not getting along which I think in part was fueled by the old arguments of Rod and Gavin who seem ‘passionate’ about their technology choices. However, there is still some animosity between the two camps years after those minor flame wars. I think part of it stems from the normal response of users being defensive, and therefore offensive or protective of their technology of choice because of flaws they are aware off even if they disagree with them, which is a normal response.

Disclaimer : I’m currently working on a Seam project and have been involved on the Seam forums. However, when I need a quick dependency injection library (especially for SE), I turn to Spring.

EJB users are having to defend a technology which has the appearance of being stodgy and has a terrible legacy even though its modern day incarnation is far more hip, cool and even Spring-like. Few negative comments about EJBs appear to be about flaws in the current implementation other than the fact that EJBs require a container.

The Spring users have to defend a technology that is in essence proprietary as opposed to standards based, and while the core Spring functionality (DI, AOP) is very good, a number of people believe that it is starting to spread itself a little too thin, and starting to suffer from the dreaded ?Bloat?. It is now facing competition from EJB, a technology that is not only as easy to use and powerful but is also a standard, which, all things being equal, is a positive. If nothing else, being a standard will also give it a helping hand in being adopted in some of the more corporate shops.

While SpringSource haven?t implemented the standards, I?m sure there will be a Spring driven implementation of Web Beans (JSR 299) which could drag Spring kicking and screaming under the standards umbrella. If Web Beans gains traction and becomes the accepted way of defining components for web applications, then there is a chance people will choose the standards based web beans syntax over a proprietary Spring syntax and be able to swap out implementations. One advantage Spring does have is the ability to provide its core functionality on both desktop and web applications which unfortunately, isn?t a part of the Web Beans spec (yet?). This may provide enough reason for developers to avoid using Web Beans or at least limit it to pieces that will definitely be web based only.

I do like the fact that the only opaque part of Spring is the container. Other pieces like the transaction manager, data sources and so on are all transparent for you to see in your configuration unlike the EJB container where they are just bundled in and magically mess with your beans. This lack of apparent simplicity can also be a turn off for some people who prefer a simpler Spring solution over complex old EJBs.

In some ways Spring feels like that small cafe that worked really well, was cheap and served great food compared to ‘those chains’. They decide to open a couple more restaurants up, and the owner can’t run all of them so he hires extra help, and trains them, but they don’t always get it right, and lack the enthusiasm with personal service. He opens a couple more stores up and decides to produce a manual detailing every aspect of the recipes and customer service. Before he knows it, he is one of ‘those chains’, and the quality of food has gone down, and the prices have gone up. Not that I think every Spring project is prone to fail unless it is under the guiding hand of Rod. However, Spring has spread beyond it’s core functionality and expecting the same level of buy-in from developers, and from Rod’s post referenced at the beginning of this post, it seems they are even trying to Manufacture buy-in.

At one time, the Spring team would have criticized the inability to move a ‘standard’ EJB from one app server to another, now they just expect you to deploy applications in their proprietary modules for their app server. They would have criticized the bloat of the implemented standards, and now if you want to use their web flow API, you have to include their Web MVC framework even if you are using JSF. I think this is a bit of a reach from the SpringSource folks. Just because I put my Dependency Injection egg in your basket, it doesn’t automatically mean I’m going to put my view technology and server choice eggs in there too.

Is Microsoft digging in the wrong place?

Java developers might feel a sense of unease relating to the number of posts predicting its demise at the hands of .net. However, developers have evolved; at least I know I have. Looking back on my Delphi days, we used to couple visual components to datasets that were then coupled to the database by a SQL statement. Insert, updates and deletes were made using cached updates with SQL statements that were generated from the select SQL. For the most part, unless you were really aware of the issue, transactions were ignored and despite it being an object-oriented language, it made rather shallow usage of the methodology.

Handling validation, corrections and formatting of fields was always a tricky affair and involved data validation code scattered throughout the application. In most cases the code was stuffed into event handlers and reproduced each time it was needed.

Over time, maintenance became a nightmare. If a field name, type or size changed it would break the dataset that was bound to that table or field. It meant having to go and manually refresh the fields on each dataset, and some changes meant having to manually modify each SQL statement that involved a particular table. For the last few years, most of my Delphi gigs have involved maintenance of Delphi applications and each time I was presented with spaghetti code where logic was strewn throughout the application in the unlikeliest of places.

One problem with Delphi is the ease with which applications can be created using a point and click interface, which is always a good thing, except for the fact that it leads to casual and lazy programming. (Un)Fortunately Delphi was never so popular that the masses picked it up, otherwise we could be swimming in a sea of bad code instead of a small lake. I like to think that those who did adopt Delphi as their language of choice took pride in it enough to do a decent job although obviously not everyone did.

Having seen and worked with Java, it is like coming out from under a rock and programming like an adult. We have frameworks that use good OO principles as often as they use ?if? statements. We can use rich ORM models to decouple the application from the database, and we use other layers and Dependency Injection to abstract everything from casual data access to complex processing so we can easily refactor at will and switch out one concrete class for another. Our domain models decouple our view and our logic from our database. The web frameworks became more plentiful and feature rich, and while it gave the developer a dizzying choice, it showed that Java folks were being creative and innovative.

Despite the choice of Java on one hand, and Delphi on the other, Microsoft chose the Delphi style of development. They chose tight coupling between data, logical and view tiers with developer tools that encourage point and click coding and discourage re-use. They chose the route that promotes lazy development and takes the user down the route of spaghetti code. I think Microsoft could have fully embraced true OO values and built it into Visual Studio.

Microsoft has taken steps to amend this with the introduction of the ObjectDataSource in .net 2.0 which allowed developers to couple their controls to lists of objects. They have also released their own action based MVC framework, which puts them only about 10 years behind java, which in software development terms is a lifetime.

There are also efforts to port the best java libraries over to .net such as spring.net and nhibernate that may encourage people to adopt better practices. I have used Nhibernate with asp.net and found it works very well, but I worry that the lack of a ?Made By Microsoft? stamp will keep it on the sidelines in most corporate shops. There are also many developers who will move to .net from VB and Delphi and continue their bad practices without thought and forge new shackles for themselves in a new language.

ASP.net pages are already being shown the door for Microsoft MVC, Winforms has come and gone in favor of WPF. If developers had separated their layers, they can put a new view layer over the business/data layer rather than have to redo many pieces with a new front end. I don?t doubt for one minute that this will be the last major upheaval to .net in the next decade. It seems like few pieces of Microsoft technology has a practical lifespan of more than a few years. Most articles promoting good practices in .net involve shallow OO principles and like Delphi, are relegated to the strange and esoteric. Why write code when I can point and click?

Looking at Delphi?s past and present, I see a future for .net with an abundance of legacy apps that require someone to jump in and untangle all that spaghetti code. It may pay the bills, and in some cases pay them well, but that doesn?t always make for relief from the misery (as a Delphi developer, I would know).

This Delphi programmer has evolved, but it seems that Microsoft has not yet made the leap, and neither have a number of their developers who keep digging in the wrong place.

Ok Saul, go bust a move, but watch out for the dead monkey.

Update : An interesting discussion on this topic has developed in this post on Fredrik Norm?n’s blog.