WanTii, Inc. Tech Blog

All professional developers have heard the phrase – “When all that you have is a hammer, then everything looks like a nail.” To many programmers, their preferred platform becomes their hammer. I will outline the reasons I prefer writing Java code, but this is mostly a response to the LAMP zealotry I come across regularly. As an experienced developer, I have learned to try to find the best tool for the job. Although this article may read like Java zealotry, I have recently written PHP and Perl code. Astute readers will also notice that this blog is based on Wordpress. So, I make an effort, as I believe all developers should, to find the best solution rather than retro-fitting my own preferred platform to the current project.

First off, let’s talk about the Java platform. Java is a collective term used to refer to more than just a programming language. It is more than just a language. Java is a language, a compiler suite, and a runtime. The Java platform is an open specification that is then implemented by a group of programmers. There are a few choices of implementation that can be used. The specifications for the Java platform are controlled by a group called the Java Community Process. The JCP creates a Java Specification Request and programmers have a document to follow when building their tools. Anyone can provide input during this process. So, typically, the JCP creates and reviews a JSR until it becomes finalized. Once finalized, the groups working on implementations will release their tools based on the new standard. Although most people use the Sun Microsystems JVM and JDK, there are others that can be used such as IBM Java or BEA Jrockit. The JSRs are reviewed to the point where tools can be built based on these documents and compatibility is usefully implemented. This process is not 100% full proof, but the development process of other popular platforms has led to incompatibilities across platforms and even incompatibilities between minor revisions. There are two main reasons why a new version of software is built, one is to fix defects and the other is to add requested enhancements. A defect can also be broken down further into a flaw in the design or a flaw in the code. When a developer is writing the code for a new release it is the design flaws that often lead to incompatibilities. If a design flaw is identified, the developer assigned to the fix will most likely have to rewrite the interface of the component so that a proper design can be honored. It is here where the community process stands out. Although many people complain about the speed with which the JCP first started to deal with the Java standards, the review process has helped to create a system with few design flaws so that if a developer writes his code using the tools available today, his software will have a long lifetime without requiring maintenance each time the JVM is updated.

At this point, experienced Java developers may be asking, “Is this guy talking about the same Java?” Okay, it is a good point. Java seemed to have a bit of an identity crisis in the beginning. When Java was first released, the world was moving toward client-server applications. Java tried to become a cross-platform environment for creating rich GUI applications. Some people remember Java applets and a few stand-alone applications. At this point in time, not only was the GUI library not as usable as intended, but Java was also very slow compared to other compiled languages of the day. At this point, it seemed like Sun tried over and over again to create a useful GUI toolset (AWT, Swing, JFC, etc.). At this point, developers began dismissing Java because just when they got the hang of AWT, it was deprecated. So much for the promise of a low-maintenance toolkit. At this point, Sun was behind the driver seat when it came to design decisions for Java. The JCP eventually took over and the computing world has moved toward N-tier applications that utilize the web as a distributed development platform. Fortunately, the problems with the early GUI toolkits are no longer considered since Java is focused on creating an enterprise development platform. This is where Java stands out. If you are not focused on enterprise development or web development, you are probably reading the wrong blog. I have heard good things about the Standard Widget Toolkit (or SWT), but I have never done professional stand-alone GUI application development.

Up to this point, I have tried not to mention any other platforms by name since it might be misconstrued as zealotry if I bashed another language/platform. I would like to compare Java/JSP to PHP though briefly because PHP has a large market share. I will not deny that PHP is a powerful platform and allows developers to write fantastic web applications. However, the closest thing to a specification is the PHP manual available online. Design decisions are made by the core developers. Although this allows PHP to evolve quickly, this evolution comes at a cost. There were a few design flaws early it PHP’s implementation that are widely publicized such as the “register_globals” issue. The lack of proper namespace implementation in PHP led to data received over the network to be inserted into the language namespace which could potentially lead to security risks. Although the risk was easily mitigated, a decision was made to change the default behavior between revisions of PHP. This caused many developers to rewrite portions of their applications. Other problems include the poor implementation of international character sets which leads to difficulties in implementing internationalization, the poor handling of quotes, and the non-uniform database access components. Feel free to blast me in the comments for not considering X, Y, or Z when discussing PHP, but these sorts of design mistakes are less common in the Java platform.

Another feature of Java is it’s relative age. Java has been based on modern development techniques and has been in use for quite a bit longer than many other languages. Many other languages are in a constant state of flux because they are learning from their previous mistakes. Java is well past that point. Java’s maturity not just as a language but in it’s libraries are a big bonus. Components like JDBC, RMI/CORBA, and internationalization/localization create a development platform that allows scalable applications to be developed with less effort than necessary in other platforms. The real bonus is the consistent design of these libraries. If you adopt Java technology and write your code as suggested in the documentation, your applications will support many enhancements that you may not realize you are supporting.

To write and run a Java-based web application is a complex, but rewarding process. The web environment is an inherently difficult platform for creating software. So why is it so popular? To me, the answer is simple, a good web application is usable by millions. Even basic tools are moving to web-based interfaces because it is so much easier to manage. Since everyone has a web browser, there client installation is easy. Browsers are becoming increasingly more compatible and capable. This means, dependencies need only be managed on the server(s) running your applications. This far reach and easy system maintenance comes at a price. Web applications require more QE testing than traditional applications and the HTTP protocol is not the greatest platform to build applications. HTTP is a stateless protocol which means each connection lives only long enough to serve it’s request. HTTP also has very weak authentication mechanisms.

Traditional CGI platforms attempt to solve these issues, but the solutions always depend on the CGI library if the developer has chosen to use one. Traditional CGI is also inefficient since a new process is spawned for each request. Many efforts were made to improve CGI such as mod_perl which allows the web server to run a script within an already launched Perl process so that a new process does not need to be spawned. These sorts of efforts led to the Server-Side Script.

ASP and PHP are all examples of server-side scripting. The difference between server-side scripting and CGI is that server-side scripts are run by extensions built into the web server. This means that rather than setting environment variables and launching a process, the script is run directly within the server’s memory. The performance of server-side scripts is much better than that of traditional CGI and server-side scripts have access to the server’s memory objects.

When the Java team decided to create a server-side scripting environment, they decided to take it a step further than other environments. They created a specification for an application server. With an application server, Java runs as a system process and the web server sends requests to the application server. The application server then processes the request and sends a response back to the web server which may or may not perform further processing before it sends the response back to the browser. The real advantage is that the app server and web server communicate using network protocols. There is also no limitation of how many web servers an app server can service. This means that a farm of web servers can be used that each send their requests to one app server. The web server cluster can then handle all the static content and only send requests requiring processing to the app server. The web servers can be load balanced and it will not matter which server a browser sends it’s next request to because the app server is managing things like sessions and authentication so that sticky-session load balancing is not necessary. This sort of scalability is built right into the platform. The technology is also matured since it was built this way from the start.

As the application server technology has evolved, most application servers run as stand-alone web servers. Since an application server can run as a web server or it can process Java requests for a server or farm of servers, the configuration of an application server is complex. Fortunately, businesses have many choices. There are commercial and open source application servers that you can choose from, and each implements the specifications so that your code will be portable between all of them. The specifications also define a mechanism for packaging web applications so that they can be easily moved and deployed by application servers. Web applications are packaged as WAR (short for Web Application aRchive). All of the web app’s dependencies and configuration are packaged into the WAR file and application servers will take this file and install (or deploy) it on your server so that installations are standardized and less likely to be botched.

There are not just advantages for systems administrators, there are also advantages for the developers. One of the biggest advantages of the Java/JSP platform is the availability of Custom Tag technology. The custom tag technology is part of an overall effort to separate business processing from presentation. Those are vague terms, so think of it this way, when the specification was written, it is clear that in the Java/JSP platform there are two roles, that of the HTML/CSS developer and that of the Java programmer. In the Java/JSP platform, Java code can be written in one of many ways. The first is to create a Java Servlet. Servlets are somewhat similar to traditional CGI scripts because they are 100% Java code. To create a Servlet, you create a Java object that implements the appropriate interface. Within the Servlet’s methods, you are passed request and response objects. There is also implicit access to other objects that may be helpful such as the user’s Session, and there are scoped containers where variables can be stored to be accessed by other components within that scope (scopes include a request scope, a session scope and an application scope). A JSP is similar to a PHP file since it is a mixture of HTML and programming code. Many programmers new to the Java/JSP platform have a tendency to write the majority of their code within JSPs. There are reasons why this is bad, but it is not the worst thing you can do. When I first started with Java/JSP, I wrote all of my code in JSPs and it was not until I was more experienced and familiar with the platform that I quit inserting Java code into JSPs. The custom tags that were mentioned earlier are a way for a Java developer to write some Java code that can be encapsulated into a tag that can be inserted into the JSP as if it were an HTML tag. Imagine working with an HTML/CSS developer to create a page that displays a user’s shopping cart. Let’s say that the current contents of the shopping cart are stored in your database, so the HTML/CSS developer has no way to access the data. You can create an object that logs into the database, pulls all of the appropriate data and creates an HTML table with the result. If written appropriately, you could encapsulate it into a tag so that that HTML/CSS developer simply puts a tag that might look like – <display:usersCart /> into the JSP file. Custom tags can be passed information (the same way other HTML tags are passed information) and even be nested. There are other useful interfaces for writing your code such as Servlet Filters and Servlet Context Listeners. Filters are useful if you want to insert logic directly in the request or response processing logic. Servlet Context Listeners allow for an event-driven programming model within your application model. If you have read this last paragraph and you are now completely lost, that’s fine. This blog entry is meant to sum up the reasons I use Java, not to instruct readers how to write Java. There will be more entries to come in the future which will expand on these ideas.

There are also architectural advantages to using a Java/JSP application server. Application servers all handle HTTP requests using threads. Although threading is also implemented by most major web servers now, application servers were doing so at the time when most web servers were still using separate processes for each request. Since application servers are written in Java, Servlets and Servlet Filters are actually extensions of the application server much the same way that Apache modules are extensions of Apache. The main difference is that the interfaces for writing Servlets, Filters, Listeners, JSPs, and custom tags are defined in a standard rather than being loosely defined by the core Apache team. The application server architecure allows for solid design and good performance. Plus, the standards teams maintain backward compatibility much better than other competing technologies.

This is a lot to absorb if you are new to Java/JSP. The point I am trying to get across is that Java/JSP is the only platform that provides a scalable architecture, promotes good application design, and performs well enough to run even the highest traffic sites on the web. All of this, and you have choice which product to run your application. You may be saying to yourself at this point, “If all of this were true, why doesn’t everyone using Java/JSP?” This is a question that I ask myself from time to time. I figure that the complexity of the Java/JSP environment presents a steep learning curve. The complexity also means that simple solutions are often harder than necessary. A good example is a project I did a few years ago. The client wanted a simple form that when filled out, would email the data to the client. The current site was static HTML running on an IIS server. To install an application server, write the Java code to receive the form contents and email them would have taken much longer than a simple Perl or PHP script. There was also no benefit and the complexity it would have been unnecessary. As you can imagine, I wrote a simple script and handed it off. It has been running ever since. So, remember, Java/JSP should not be your hammer, but it is definitely a useful tools, particularly when you are planning a grand project.