In web applications if there is a requirement to protect the site to restricted users or groups of users there are different ways to achieve it. The traditional way of doing it is to have it the program way, to have the users and group information stored in a database and providing a login page to allow a user to login. The user credential is authenticated and the application authorizes him/her access to features and functionalities based on the privileges available to him/her. All these information comes from the data store which could again be administered and managed through separate programs or part of the same application. The user administration will have to be part of the requirement and will require effort implementing through program code.

With declarative security, the application server container takes care of protecting resources of the web application through roles, authorization and group management and appropriately restricts the user from getting into or accessing specific pages in the web site. J2EE certified application servers support declarative security. The authorization details can be mentioned through the web deployment descriptor (web.xml). The Weblogic resource “Declarative Security” has some insights on using web.xml to protect the resources. The security chapter in J2EE tutorial is also a good resource to understand declarative security. The best way to have an efficient security is to have a combination of security approaches as this article “Declarative Web Application Security with Servlets and JSP” explains it with samples.

If you are dealing with converting string to numbers particularly a currency with locale specific formatting (surch as $10,300.83-) then the default parseInt/parseFloat in Java will not help as it would throw a NumberFormatException. This article “Resolving NumberFormat’s parsing issues” in IBM developerWorks describes how the class java.text.NumberFormat can be used effectively to solve locale specific conversions.

One of the good design principles is to program to an interface. What does programming to an interface mean? An easy way to explain this is to think of the domain model of a system to be defined in terms of (Java) interfaces. These definitions are like vocabulary of the system as these do not contain implementation but just declarations. The system using the domain works against the interface and does not know what is going to be the implementation until run time. A factory, a broker or a container could actually help get an implementation during runtime. The key advantage is the layer that uses the interface is loosely coupled with implementation and there could be several implementations of the domain model that suits specific situations/needs. What other advantages does programming to the interface bring? And why not an abstract class instead of interface? This, year old interview “A Conversation with Erich Gamma” by Bill Venners best answers these questions.

A recent article on java.net had this interesting question “Why Do Pointless if Statements Even Compile?“.  I went through the article as well as the comments made by readers.  It is a good one, made me think and the question seems to be really valid and not at all a stupid question.  I think it would be all the more costly to do a check in the compiler rather than just allow it as it is syntactically right.  The only time this would produce a side effect is when the if condition does not have an else. Otherwise putting an else would throw a compilation error “else without if”. Following a coding standard and using code check utilities like checkstyle can also help. Nevertheless it is an interesting question.

File signatures are useful to identify a file type. This approach had been there for a quite long time. For example when a JVM has to load a java class file the first thing it would check is if it is a Java class file. In order to do that there is a magic code that identifies if the file is really a Java class file. What is this magic code and how do we see it? Keep reading.

In order to check the signature of the java class file we need to have a tool that can help us view its initial bytes in the form of hexadecimal codes. Interestingly if you are using a Windows system there is an easy way without the need to go for a tool. DOS had a tool called debug which allowed developers to look at assembly code of an executable. This tool loads an executable COM file (like command.com) and users can view every byte of the file in binary and hex. Debug is still packaged with Windows and we can use it to look at the class file in binary and hex.

But there are two constraints to use debug. The debug command still thinks that it is running under DOS and will load only a COM executable. Next thing is the DOS 8.3 file naming limitation; if you have a file that has the prefix more than 8 characters and suffix more than 3 characters, debug will not understand it. So here is how we are going to cheat debug thinking that it is loading a COM executable by simply renaming the class file extension to a com extension and also confirming to a DOS 8.3 file naming convention.

I created a screen cast that will show you how to view the signature of the java class file using debug tool.

Why CAFE BABE? Maybe James Gosling and the team thought it sounded sexy and also Cafe went good with Java. But up till now to my knowledge the real reason behind this magic code is not known.

With the above technique you can try out the magic codes for other file types.

Automated build scripts are like any other code that will require some maintenance and enhancements then and there.  The scripts could be reused and altered to different projects or for the same project but how easy it is to do depend upon how clean and maintainable the script is.  Here is a good article from IBM developerWorks “Automation for the people: Remove the smell from your build scripts” that gives few tips on writing a cleaner maintainable automated build scripts.

If you are new to build automation read my series of posts on Build Automation.

It is apparent that the X in AJAX stands for XML, but if you have used AJAX it is most likely that you may not have encountered XML as such anywhere in the request/response. Probably you might not have encountered use of XML because your server is not expecting an XML because as far as the server side is concerned it does not matter whether the request is synchronous or asynchronous. Its job is to serve the request and respond back. But there might be situations where the server might be expecting a XML based request. For example let’s say the server has to communicate with some web service for the response. Then if the request is in XML it saves some time and as a simple translation could be applied to frame the request to be sent to the service. Here is a part “Using XML in requests and responses” from the Mastering AJAX series from IBM developerworks that explains with example of how to use AJAX with real XML request and response.

My post “Use of Flash for rich web applications” talks about using Flex as a presentation layer framework to utilize the power of Macromedia Flash for rich UI application. Here is a simple tutorial on using Flex - “30 Minutes Flex Test-Drive for Java Developers“

Happy Weekend!