10 FUDs on Open Source Softwares

Open source softwares play a key role in reducing the effort required for any software application. Many of the cross cutting concerns in software development will be addressed by open source softwares and the developers can just concentrate on implementing the business functionality alone. But, when we think of using an open source software as the critical component of the application (such as core framework or the server runtime), both managers and architects may have many FUDs (Fear, Uncertainty and Doubt). This write up tries to analyse some of those FUDs. Please note that when I say open source software (OSS), I generally mean a stable software with good community involvement. (Eg. Apache Tomcat)

FUD 1: Open Source Softwares will have lot of Bugs
I will say that any software will have bugs initially. The important thing is to unearth them at the early stage and fix them.
Most of the popular OSS will be downloaded and used by hundreds of people. The good thing is that they will not be using it just for the purpose of testing. They will be using it in their real business scenarios. All the major bugs will be reported during this time and most of them get fixed as early as possible depending on the criticality. Another point to mention here is that, people will start using the software even before the final release is out. So, by the time it get released, most of the bugs would have been fixed.
In short an OSS will be tested by hundreds of testers in the real business scenario. And their commitment will be more, when compared to a few salaried testers in a company, because they are the real users of the software and it is very important for them to ensure that there is no major issue in the software.

FUD 2: If there is an issue who is going to support me
Almost all the commercial softwares have an option to opt for professional support. In case of open source software, there is always a concern on who will provide support when something goes wrong.
There are multiple points to be noted here
a. Forums provide support
All the popular OSS have very active forums. 99% of our issues would have been already faced by someone else before. So we will get the solutions directly from the forum. If it is not already addressed, we can post our issue, so that someone else could respond to that.
One problem is that, there is no SLA associated with these forums and there is no guarantee that we will get a response. There are some guidelines to be followed while posting in such forums.
1. Be specific. Focus on our real technical issue and explain it in detail without mixing it with our business requirements.
2. Don't just say that "I have this issue. Please help me to solve this". Explain the options we have tried and their results.
3. Don't just be a leecher. Be a contributor. Remember that community is all about give and take. Contribute to the forum wherever possible. If we are active contributors, we have better chance to get response for our queries. Being active in the community, we may even build good rapport with the key developers of the  OSS.
Forum based support is very less for most of the commercial softwares, as the number of users will be less and there is no active community.

b. Easy to help ourselves with debugging
Being open source, we have the full source code of the software available with us and we can easily debug our issues on our own. We can look into the internals of the software and see how the inputs are getting processed and what is the root cause of the issue.

c. Commercial support options are available for OSS
If you still want the peace of mind of a commercial support, you have that option for most of the OSS. Many vendors provide commercial support for OSS.

FUD 3: Whom will I blame if something goes wrong
Proprietary software from big vendors are often used as a protection mechanism in front of customers. Generally we try to say that it is an issue with X software and we are in touch with Y company. This will help us in keeping the customer quiet for a few days, especially if Y is an industry giant. But what is the reality here? After all, our customers are valuable to us and it is not fair to cheat them.
In my experience, it is very difficult to add value from a commercial support for a proprietary software. We, application developers, sit at one side without having the full picture of the proprietary software and the vendors sits at the other side without having the full picture of our application. Support providers can mostly give just some hints, on which we need to work based on our experience and resolve the issue.

On the other hand, if it is an opensource software we may not get the protection I mentioned initially. But we will have the full picture of both our application and the open source software, and thus we will be in a better position to resolve the issue in quick time, for the benefit our customer.

FUD 4: OSS may perform poorly when compared with commercial counter parts
Most of the proprietary softwares are developed after doing a great amount of research with proper planning and design. OSS normally evolve over time based on the need. So there is a high chance for proprietary software to perform better than OSS.
There is also another side for this. Normally proprietary software will  be overloaded with lot of features which can provide them marketing benefit and this can make the software heavy. On the other hand, OSS may be lean and lightweight with just enough functionality which is most relevant.
Conclusion is that, only by critically evaluating the software we can make a judgement on performance.

FUD 5: It is very difficult to develop, manage and monitor as I don't have a good console or IDE.
This is a point where I generally tend to agree with the FUD.
Proprietary software will normally have good user interfaces, because that is a key element for them to market the software. But open source software will mostly concentrate on the core engine. We may need to do some less user friendly operations like editing some configuration files. Monitoring the software also can involve some manual technical activity. For many proprietary softwares, all these could be possible directly with console/IDE.

FUD 6: My customer may not like the use of OSS
When we are doing a services project for customers, this can often become an issue. There are organisations whose policies will not permit the use of OSS. And CIOs of some organisation may not have trust in OSS. In the second scenario we can try to convince them on the merits, with very little chance of success. This may be a case because of which we may need to avoid OSS.
But when we are selling products, things could be different. It is our product which we are selling and it is we who provides guarantee for the product. Here the customer need not worry much on what we are using within our software. After all, most of the commercial softwares, especially in Java world, use open source libraries within that.

FUD 7: If I need an extra feature, what will I do
Getting a new feature implemented in any software is a challenge no matter whether the software is open source or proprietary. Let us see what are the options available in both cases.

Enhancement in proprietary software:  Most of the proprietary softwares will have a standard roadmap. It will be very difficult to get a new feature implemented, if it is not available in the roadmap. Depending on the merit of the requirement, its complexity and our relationship with the vendor, we may be able to manage some of the requirement. But we cannot expect a major enhancement to be done just for us. Here, if the vendor is not doing the enhancement, we don't have any other choice as it is a proprietary software.

Enhancement in opensource software: In case of open source software, we have multiple options.
1. If it is a small enhancement needed by many, we may get it done by the community quickly. Otherwise we may need to wait.
2. Since it is an open source software, we always have the flexibility to update the source code for our need. This can be done in two ways.
a. Branch out from the original source, make our enhancement and check-in to the community. There are  multiple advantages in doing this. There is a high chance for our code to get merged with the main stream of the OSS, if it is really worth. If this happens, we don't need to worry about the maintenance of that source code anymore. If the feature is attractive to others, they will also start contributing to it and we will get benefited with it. This will also help us in getting better acceptance in the community.
b. Take the source code and enhance it without contributing back to the community. By doing this way, we can keep our intellectual property with us. But we don't get the advantages mentioned in the previous point and maintenance of this library will be our headache from now on. There are organisations who don't have a proper policy for contributing back to the community. So this may be the only option available in such cases.

Here we can see that OSS has the flexibility of multiple options in getting an enhancement done. OSS is much better placed when compared with proprietary software in this context.

FUD 8: Will they stop development of this software
This risk is there for both OSS and proprietary softwares. We have seen many softwares getting discontinued in the past in both cases. What we can do once this happens?
In case of OSS, we have the full source code available with us and we can maintain it as necessary. And, if it is a widely used software, there is always a chance for some other community to take it up. Mostly, many users of the OSS take initiative and start a co-development. We can also be part of that and have a say on the future of that software.
In case of proprietary software, we don't have choices as there is no control or visibility on the source code.
This means proprietary software has higher risk than OSS.

FUD 9: Will they change the license and make it commercial
We have already seen many open source softwares change the license to become proprietary.
Few points to be noted here

• There is very less chance for a community driven software to become proprietary. 
• Most of the open source licenses are perpetual and even if the software becomes proprietary, it doesn't affect the license we already obtained. We can still continue to use the open version we obtained and we have every right to maintain it. 
• Just like I have mentioned in the previous FUD, a group may fork the source from the available open version, and will start to maintain it, if it is a popular software.

FUD 10: Will I fall into some legal troubles if I use OSS
There are many cases where organisations fall into legal trouble because of the improper use of OSS. It could be a software which requires commercial license for production deployment or it could be a GPL software which is used in proprietary product. It is very important to read the license clauses carefully and ensure proper compliance with it. Once we confirm that we are fine with all the license clauses, we are safe to use it.

Choosing the right open source software
Choosing the right open source software is very important. We need to consider following points while we choose it.

• Does the software satisfy our key requirements?
• Is the software well maintained?
• Does it have a good roadmap?
• Is there a reliable community behind the software?
• What is the general opinion about the software?
• Is the software stable?
• Does it meet the required performance needs?
• Does it have a safe license?

If we choose the right software considering all these facts, you don't need to worry about the above mentioned FUDs.

Closing Note
Most of the FUDs on open source software are mere FUDs, not facts. Whether a software is open source or proprietary is not the parameter to judge it. What matters is the value added by the software in terms of features, stability, usability, performance, popularity etc. All these parameters need to be thoroughly evaluated before choosing a software. And, if you get multiple softwares which suits your need.,  my recommendation is to go with open source software, because of the flexibility and control it offers.

Is Adobe getting bored with Flash/Flex?

Over a period of last one year HTML5 specification was becoming popular and there were questions like "Will HTML5 replace Flash/Flex". We have also seen many hot debates on it. But none of such debates went into a solid conclusion.

My view is as follows.
Here a standard is competing with a proprietery technology. This can introduce two major considerations.
1. Accessibility: Being client side technologies, both need to be supported over varying hardwares (Mobiles, Tablets, PCs), operatings systems and browsers. This support requirement always gives an advantage to standard over proprietary. We already have many industry giants aligning behind HTML5.  And there could be corporate politics running against propritery technologies.
2. Reusable assets for development: Being a standard, open source communities are excited to develope reusable components around HTML5. Even though the specification is still in draft state, we already have a lot of great HTML5 components in the open source space. This will never be the case with Flash.
So HTML5 should be the final winner. However it will take a few years for the industry to get adopted to that and Flash/Flex will live till that time.

And now, what is Adobe's view on it?
Being the vendor of Flash and Flex technologies, I was expecting Adobe to become more agressive and improve these technologies so that it can give next level of advantage over HTML5. But with some of the recent announcements, it looks like Adobe is trying to adjust to the reality.

1: No More Flash on Mobile Browsers
In Novemeber, Adobe announced that they will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (http://blogs.adobe.com/conversations/2011/11/flash-focus.html). In the post, they clearly stated that HTML5 is the best solution for creating and deploying content in the browser across mobile platforms. So that was a clear answer to the question "Flash or HTML5" at least for the mobile devices.

2: Adobe donates Flex to Apache. 
Again in November, Adobe announced that they are donating Flex to Apache community. (http://www.adobe.com/devnet/flex/articles/flex-announcements.html) Well, this could be considered as a positive or negative action. Postitive part is that, if Flex gets into Apache, we will have more enthusiastic committers working for it, along with developers from adobe. As per the latest update, Flex is accepted for incubation in Apache (http://incubator.apache.org/projects/flex.html). Negative part is that, it looks like Adobe don't want to drive the Flex development or roadmap and they may not be investing on it as much as they were doing earlier. And again in Adobe's official blog there is a statement "In the long-term, we believe HTML5 will be the best technology for enterprise application development."

So I believe, Adobe has accepted the reality that, HTML5 will take over the position of Flash/Flex in due course of time.

Enterprise Application Development using Spring Roo 1.2

Spring Roo is an open source Rapid Application Development tool for Java developers. Spring based applications performing CRUD (Create, Read, Update, Delete) on Entities can be easily auto generated using Roo. It is not an IDE or a runtime. It is just a programming methodology combined with a code generation tool. This post describes the features of Spring Roo briefly and analyses its applicability in building enterprise applications where simple CRUD functionality and auto generated screens may not be sufficient.

Spring Roo Features
It is very easy to kick start a Spring Roo project. You just need to give few commands and the project will be ready for you. Then you can provide information about your entities, their fields and constraints. Spring Roo can generate end to end code for all CRUD operations. The generated components include JSP pages, MVC Controller classes, Entities with their persistence logic and database tables. Roo can also create custom finders with filter fields of your choice. From version 1.2 onwards, you can also generate service layer and repository layer if you wish. 

Other key aspects are as follows:

• Roo has excellent round trip handling. Most of the auto generated code is at your disposal to edit. Roo accommodates your changes even when it recreates the code. This ensures that most of the NFRs required for an Enterprise application are available off the shelf. 
• Roo generates application on top of robust Spring framework. 
• It has integration with many of the industry standard frameworks like Hibernate, Spring MVC, log4j, Google Web Toolkit, Solr search engine, EclipseLink, OpenJPA etc
• Application runtime is independent of Roo. Role of Roo ends in development cycle.
• Supports Database Reverse Engineering. 

You may read more about Roo features in my older post. 

What else you need for an Enterprise Application? 

If an application is being developed for internal use of an enterprise, you may be able to use auto generated application as such with some tweaks. But, if the scope of the application is beyond that, you will have additional requirements.

• There will be complex business logics to be performed. 
• Even for simple CRUD functionality, you may need custom screens to improve aesthetics and usability. 
• You may have strict NFR requirements in terms of performance, security, transaction management, logging, audit, internationalization, maintainability etc. Your application will require a robust architecture to support all these. 

So the key requirements here are customizability to the customer needs and adherence to NFRs. We will see each of these in detail.

Architecture Analysis
Following diagram describes the architecture of a typical Roo based application, when service and repository are enabled. 

High Level Architecture of a Spring Roo based application (Click to enlarge)

You may notice that the architecture is robust with appropriate layers and proven technology components. 
Note: In most of the cases business services and repository will not be doing anything other than delegating the call to underlying layer. But presence of these layers can provide great peace of mind to 
a) an architect, because of the flexibility it provides for any future requirements.
b) a manager, because the architecture resembles any other proven enterprise architecture he would have already seen.

Customizability
For any auto generated application, the extent of customizability will be a major concern. Let’s now look into the customizability of Spring Roo based applications.
Depending on the requirements, Spring Roo applications can be customized to different extents, and there are side effects for some of the customizations, especially when we try to modify the data model after customization. For example, when you add a field after doing the customization, some times, you may need to tweak the code a bit.

UI Customization
Look and Feel: User interface is the area where maximum customization is required, because the end user directly interacts with it. You may change the overall look of the application by modifying its stylesheets, images and template files. You can also modify the property files to change labels, titles and messages. All these changes are completely non-invasive and Roo will keep these changes intact even when it updates these files. 

UI Components: All the html fields are represented as tagx components in Spring Roo. If there is a requirement to change the behavior of a field, it can be done at the component level, so that all the pages will be changed automatically.
Additional Client Side Logic: It is possible to add custom Javascripts to perform client side logic like doing a specific validation. 
Page Layout: Roo generated pages will have a normal two column layout. But we can modify the layout by including table or div tags around the fields without touching the field definition. This gives us complete flexibility in page layout.
When new fields are added to the screen, Roo will update the file we have modified. But it will keep our layout tags intact. Once it is re-generated, we may need to properly place the newly generated fields in our layout infrastructure, because Roo doesn’t understand our layout logic. Similarly, when a field is removed, we may need to readjust the layout of other fields.

Business Customization
In some cases we may need to add additional business logic, other than simple validation and persistence.  With the help of newly added service layer, this is very easy to achieve. By default, the service implementation class will be empty and the actual implementation will be in ITD file (Click here, if you are not familiar with ITD). You can define the same method in the implementation class with additional logic, and Roo will automatically remove the default method from the ITD file.  

Introducing New Functionality
There could be certain functionality which are complex and will not match to any CRUD operations. Eg. A flight availability search. You may need to create the entire layers for such functionality without the help of Roo and update the menu generated by Roo to give link to the new functionality. Depending on the modularity requirement, new functionality can be implemented as new classes or as additional methods in existing controller and service classes. In some cases, it will be possible to reuse the auto generated persistence logic itself and we just need to create the screen and business logic. If we need to update persistence logic as well, we may modify the entity (if we are using active record pattern) or add a new dao class. It is absolutely ok to mix Roo and “non Roo” functionality in a single application. However it is recommended to use a technical architecture which matches with Spring Roo architecture, ie and architecture based on Spring and Spring MVC. 

NFR Support

Adherence to Non Functional Requirements is important for any enterprise application. Let us investigate how the well the NFRs can be addressed in a Roo based application.

Security
Security can be easily incorporated to Roo based application using Spring security. Intercept-url tag in spring security can be used to enforce authorization at presentation layer. As the URL for all CRUD operations of an entity are same, you may need to use http method also to enforce fine grained access control. But if service layer is used, authorization can be easily enforced at service layer by adding MethodSecurityInterceptor using AOP. 

Performance

Roo does all the work during compilation. Once the Roo based application is compiled and deployed, it is just like any other web application. So there will not be a performance impact due to auto generation. 
The architecture uses Spring MVC at presentation layer and Spring at business layer and they are well known light weight components. 
The only area where we can have some performance concern is the persistence layer. As the entire persistence layer is ORM/JPA based, there could be performance issues in bulk retrievals, especially when dealing with entities with children. You may mitigate this issue, by updating service class to invoke a separate DAO which invoke JDBC calls for performance critical reads. 

Transaction

If we opt to have a service layer, transaction is enforced at service layer. Otherwise, transactions are enforced at the domain layer. As normal CRUD functionality generated by Spring Roo deals only with one entity and its children, transaction enforcement at domain layer is sufficient. When we add a functionality which deals with multiple entities, we need to have a service layer which interacts with these entities and the transaction can be enforced at service layer.

Logging

Spring Roo has off the shelf support for Log4J and it could be used for any logging requirement. Interceptors can be put into service and persistence layer to introduce generic entry/exit logging.

Audit

The recommended approach is to use Entity listeners to perform audit. Alternatively custom implementation can be provided using interceptors. 

Internationalization 

All the labels and messages in the application are externalized to property files. So the application can be easily localized for any language. 

Maintainability

Roo based application has excellent maintainability due to the ITD approach. In all the Java classes from presentation controller to entity, auto generated code is separated into ITD files. So, by default, Java files will not have much code. We will be adding our custom logic in these Java files and even after that they will be lean, as normal setters, getters, persistence logic, delegation etc. will not be present in them. It is easy to maintain these classes as they contain just enough code that a developer has to see. Any other code which does not need a human brain to maintain are separated and thus maintainability of a Roo based application will be better than a normal Java application. 

Scalability & Availability

As already stated, Roo does not have any role at run time. A Roo based application will be just like any other application based on Spring and Spring MVC. As we all know, Spring and Spring MVC are most light weight and stateless frameworks and they can be scaled to any level. By providing a proper deployment architecture, any level of availability can be guaranteed for a Roo based application.

Recommended Approach
For an enterprise application "generate and forget it" approach will not be sufficient. The approach should be "generate -> tweak -> enhance -> deploy"
Steps could be as follows.

1. Decide on the functionalities for which Roo will be used.
2. Finalize the domain model as far as possible.
3. Auto-generate the functionality using Roo, enabling service and repository layers.
4. Make customizations in styles, images, labels, top level layout etc.
5. Modify the UI components wherever required. 
6. Modify the .jspx file to change the layout of the pages, if required.
7. Add additional Javascripts if required.
8. Customize Service and repository classes by overriding the auto generated methods.
9. Add new manual webpages, controller methods and entity methods for custom functionality  wherever required.

Conclusion

Spring Roo is a robust and reliable mechanism to perform Rapid Application Development. Roo acts during compile time and this ensures that auto-generated application will be highly customizable. As the application is Spring based, it can leverage all the strengths of Spring framework. 
Spring Roo can surely improve the productivity in development of normal CRUD functionality, without compromising the flexibility and NFRs. Complex functionality in the enterprise application can still be developed without using Roo. Roo based functionality and other functionality can coexist well in an enterprise application.
Features provided by Roo 1.2 made it more favorable for enterprise application development. 

Are we ready for HTML 5?

As we all know HTML 5 is the web specification which focuses on rich internet application development. It will surely change the way we look at web now. The "thin client" will not be thin any more. This post tries to analyse whether it is the right time for us to start development in HTML 5.

The post is very much similar to my previous post, although the title is entirely different. Last time I talked about dropping IE 6 support. This is about embracing HTML 5. But the concerns in both topics are identical.

To know whether we can use HTML 5, we need to see which all browsers supports this. Sites like http://html5test.com/ will give you a clear idea about HTML5 support in various browsers. Here we can see that latest released versions of all browsers (except IE) supports most of the features of HTML 5 even though the specification is still in draft stage.
Last sentence is a positive statement but there are three negative points in it.
1. Specification is still in draft stage
2. Browsers supports Most of the features of HTML 5 (Not All)
3. All browsers except IE.
We will see each of these points one by one.

The Draft Specification
"The specification is still in draft state. So how can I develop something on top of HTML5 today? If the specification itself changes tomorrow what will happen to all my codes?"
If you look at W3C process, we can see that draft itself has various levels. So draft is not just daft. In May 2011, W3C announced that HTML 5 is going to "Last Call". So what is this last call? According to W3C, (http://www.w3.org/2005/10/Process-20051014/tr.html#last-call)  "Ideally, after a Last Call announcement, a Working Group receives only indications of support for the document, with no proposals for substantive change". This means there will not be any substantive change any more and we are safe. Hold on. There is one more statement. "In practice, Last Call announcements generate comments that sometimes result in substantive changes to a document". So there are chances for substantive changes. It is something like a bug report which result in change of functionality. But, we need to assume that the impact of such changes will be minimum. And as of now, there are only a limited set of issues and objections in the W3C list. There are many areas in the specification where all the browsers already have stable implementations (Eg: Canvas).  I don't think we need to expect any changes in such areas.

Feature Support in Browsers
"There is no consistency in the features supported by browsers. So how will I ensure browser compatibility"
Yes, features supported by various browsers are not consistent as of now. But final destination of all browsers are same, even though the path taken by them are different. At some point of time all will reach the target, ie full HTML 5 support. So if we adhere to HTML 5 standards, it will work in all browsers after some time, even if it is not working now. But that day is not "today" or "tomorrow". So time to market has to be a major consideration while deciding to go for HTML5. In my opinion, If your target application needs to be released before mid of next year, HTML5 may be a risky business. But if you have enough time and if you are designing a system which is expected to sustain for the next ten years, going with HTML5 will be a better bet.

Internet Explorer - Headache
"When will HTML 5 be supported in Internet Explorer"
As of now support of HTML 5 on Internet Explorer is very less. There was huge expectation on IE 9 for its HTML 5 support. But, as per html5test.com, support in IE 9 is not at all in acceptable range. HTML 5 support score for IE 9 is 141 where as all other browsers has score around 300. In short we cannot consider IE 9 as an HTML 5 compatible browser.
However there is something promising about Internet Explorer 10. IE 10 platform preview 3 scored 300 points in html5test.com. By the time it is released, we may have an even better score. But there is a bad news. IE 10 is supported only on Windows 7 or later. This means more than half of the current computer users in the world will not be able to experience HTML 5 on IE. Just like we talked about IE 6 support, this will be an even painful issue for any public facing sites. For corporate applications, corporate can influence the users to use a particular browser. But for any public site, the vendor will not have this option. If they need to go for HTML 5, they may still need to have a fully functional (less user friendly) non-HTML5 basic version of the site to support legacy IE versions or older versions of any other browser. (Eg. Basic version of Gmail)

Conclusion

If your target application needs to be released before mid of next year, going for HTML5 may be a risky business as browser support is yet to stabilize. But if you are designing a system which is expected to sustain for the next ten years, HTML 5 will be the ideal option. For public facing sites which require near 100% market penetration, you may still need to have a fully functional (less user friendly) non-HTML5 basic version for older browser support

IE 6 Support Dilemma

Often there is a dilemma among web developers whether they need to support Internet Explorer 6 or not.
Problem with supporting IE 6 is that, it is very complex, especially if you are building rich interactive web sites. Many functionality may not work and many other functionality will have extremely sluggish performance.
There are many campaigns running on behalf of dropping IE 6 support. Eg. http://idroppedie6.com/ , where you can register your website and declare Independence from IE 6.

Before dropping IE 6 support, we need to see whether any one uses it. Yes, many use it. If you check  browser market share statistics from various sources, you will see that around 5 to 10 percentage of the users are still using IE 6.
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
http://en.wikipedia.org/wiki/Internet_Explorer#Market_adoption_and_usage_share
So question is whether you need to support (or rather, get business from) these 10 percentage of the users or not.
But why all these people are still using IE 6? My assumption is as follows. Almost 50% of the computer users are still using Windows XP. It may have shipped along with their computer and there are only a very few users who upgrade the OS. Default browser shipped with XP was IE 6. Among this XP users, there is a section who may not have enabled Windows Update and so they are not upgraded to IE 8. And there will be yet another section who may be using pirated Windows XP and so they don't have an option of windows update. But from a business perspective, can we say that we don't need business from those who are using pirated softwares?

The million dollar question is still open - "Do I need to support IE 6?".
In my opinion, if you are developing a public website whose usage will impact your revenue, you should support IE 6. Now the problem is that, if you develop a rich web screen, it will always have issues in supporting IE 6. My suggestion is to have a highly user friendly web application, targeting the newgen browsers such as firefox and chrome. And in addition to that have a fully functional but less user friendly version of the same application to support IE 6.
But if you are targeting corporate users, you may need to support only new generation browsers. Here the advantage is that corporate can instruct the users to use free newgen browsers like firefox or chrome.
You can also check the usage pattern of your website and find out the browser usage share, Using this data you may take appropriate decision.

Spring Roo - An excellent RAD tool

Recently, I had a look at Spring Roo,  http://www.springsource.org/roo 
Roo is part of Spring family and it is an open source Rapid Application Development tool for Java developers. Spring based applications performing CRUD (Create, Read, Update, Delete) on Entities can be easily built using Spring Roo. It is not an IDE or a runtime. It is just a programming methodology combined with a code generation tool. 
To set up an application using Spring Roo, you may need to enter a few commands on the Roo shell. After that you can create your entities and add fields to it. Roo shell running in the background will create all the artifacts required. The application will be ready to run with full CRUD operations for the entity. 
Generated artifacts include 
• A listing screen which lists the entities in a table with pagination. Delete and update can be triggered from this screen 
• A create/update screen to create/update one entity. 
• A view screen to view one entity. 
• Spring MVC Controller class for performing the operations on the entity 
• Java bean setters and getters for entity. 
• Persistence logic for all CRUD operations for the entity. 

Finder Generation 
If there is a requirement to filter the listing based on a few parameters, finders can be generated. You just need to add an annotation to the entity and Roo will create the screen and corresponding logic for the same. 


Excellent Roundtrip handling 
Most of the Roo generated codes can be edited manually. Roo shell will automatically detect that and adjust the application accordingly. Even when Roo updates those files later, the manual changes will not be overwritten. 


It is nothing but Spring 
This is one of the unique features of Roo. The generated application is nothing but a normal Spring application. It gets the entire strength of the robust Spring framework. It is easy to build all the NRFs into the application. For example, authentication and authorization can be performed using Spring Security.  This makes Roo a strong candidate for developing enterprise applications, without compromising on NFRs.

Maven Dependency Management 
Dependency management in Roo is very easy as it is handled by Maven. As and when new features are added to the application, roo will automatically update the pom.xml and maven will download the dependencies. 

JSR-303 Bean Validation 
Spring Roo performs data Validation based on JSR-303 annotations. 

Integration with industry standard frameworks 
Other than spring, it has off the shelf integration with industry standard frameworks like Hibernate, Spring MVC, log4j, Google Web Toolkit, Solr search engine, EclipseLink, OpenJPA etc. 

Roo independent runtime 
The role of Roo ends in development cycle. The runtime of your application does not have a dependency with Roo. Spring Roo even provides a guideline on how to remove Roo from the application without affecting the functionality. 

Eclipse Based IDE 
Easiest way to develop in spring roo is to use STS (Spring Tool Suite) which is nothing but eclipse with a few extra plugins. 

Flexibility 
An important advantage of Spring ROO is that it gives you maximum flexibility. Once you do the automated generation, almost entire code is at your disposal, and you can do any modification to that as you wish. The generated code is very clean and easy to understand. So even though you are working with generated code, you will not have any restrictions of generated code. 
And it is not mandatory that you following Roo based approach for all screens. You can use Roo to build your simple CRUD functionality and use a normal Spring MVC-Spring-Hibernate architecture to build complex functionality. As the technology stack is generally same, they can easily coexist. 


In any enterprise application, a large amount of functionality is simple CRUD. Spring Roo can surely improve productivity in developing such applications.