SZ Quadri - java tag

Too much abstraction is bad

Tue, 26 Aug 2008 10:20:42 GMT

I always felt annoyed casting ServletRequest object to HttpServletRequest whenever I am programming using java servlets. The servlet API is designed so that it abstract away Http protocol and looks at the big picture in which you may also have FtpServlet or PoP3Servlet. But, as every JSP developer knows, till date we have not seen any implementation of the servlet API for any other internet protocol so wasn't it much better that Sun Microsystems would have created the API specially for handling HTTP protocol based servlets allowing developers lot more hand-coding productivity?

In the above example I just wanted to show that casting the abstract object to specific type every time you want to use it is unnecessary.

In other cases, abstraction may adversely affect the performance and scalability of the overall/final application itself. Take the example of old EJB specification. A significant number of developers were using just jsp/servlet based client for connecting to EJB layer and so abstracting the whole business logic in EJB that too working on marshaling/unmarshaling using Remote objects was overkill!

I was facing the same issue when designing a framework for our web applications. I was faced with choice of creating it very abstractly, making it easy later to make it independent of Http protocol thereby making is suitable for non-web / desktop applications as well. But finally I realized that if there is no short term, there is no long term. So an ideal choice was to make it abstract as much as possible without losing the lightweightness, to-the-point and easy to understand naming conventions and overall developer productivity. In short I chose 'abstraction' but not 'too much of it'!

5 Reasons we chose BIRT instead of Jasper or JFreeReport

Wed, 22 Aug 2007 06:57:35 GMT

A year ago, I was looking for a way to integrate complex/graphical reporting into our software offerings. I was sure that the way is to find a open source project that has the right kind of license and right kind of technology. Regarding licensing, I wanted to make sure that we should be able to use the reporting engine/technology in our commercial softwares. I evaluated JasperReport, JFree Report (now part of Pentaho) and of course, BIRT. Here is what I liked in BIRT

BIRT is an Eclipse project: This made sure that the project is going to be live and evolving (as an open source project) in the times to come and will become more feature rich as the time passes. We were not afraid that someone is going to close the source directly or indirectly (by selling documentation at high prices) by creating a future version that will require commerical support to do anything but trivial.
BIRT uses standard technologies to the maximum level: It uses HTML for layout related things, JavaScript for scripting and CSS for styling! It naturally means we can leverage the existing knowledge that our developers have in creating the kind of reports our customer want. Faster and at lower costs.
BIRT offers very good GUI Designer: A graphical designer not just makes your life easier while developing the reports but you can also give it to your customers so that they can also do some small changes that they might need here or there in the report. Most important thing is that BIRT designer is group of plugIns for Eclipse IDE and hence quality of the report designer is excellent.
BIRT has a very nice Web Viewer: Yes it comes with nice pre-integrated ajax enabled web viewer that your can run from Tomcat (our favourite) or any other Application Server in less than few minutes.
BIRT has quality documentation, sample database, example reports: All this reduced the learning curve to a very affordable level.

If you are looking for a serious reporting solution (open source), I will recommend that you should consider evaluating BIRT. May be you can find the technology you are looking for.

NetBeans 6 Preview is quite stable.

Wed, 04 Jul 2007 08:23:00 GMT

Today, I downloaded and tested NetBeans 6 Preview release (M9). It seems to be stable enough for production work as well. We were waiting for some stable release of Net Beans IDE version 6 for quite some time. This was since we had decided to use unified EL in new version of our web application framework 'netForce'. Tomcat 5.x does not support unified EL; and NetBeans 5.x does not support Tomcat 6. So we had no option but to wait for the release of version of NetBeans IDE that can support Tomcat 6. NetBeans 6 is scheduled to be released in last quarter of 2007 but the preview release seems to be stable and promising enough to encourage us to use this IDE for active development of new version of our applications. Kudos to the NetBeans team. We are also impressed with other overall improvements in IDE. Most of our work is done using NetBeans IDE. The only exception being reporting, for which we have to use Eclipse since we are using BIRT reporting engine. BIRT being an open source software, I wonder if someday we will have a NetBeans module providing support for BIRT.