For the past year or so I have been working on a web development project using Java.  Like many Java projects, the project I was working on used 3rd party frameworks like Spring and Hibernate rather than utilizing the official Java EE stack.  Many developers have turned to these frameworks because the official Java EE stack had been notoriously cumbersome and difficult to use.  That is starting to change.  Java EE 5 started moving Java EE in a new direction.  Inspired by the ideologies of the 3rd party frameworks, the JCP, the standards community that works on the Java specification, began to make radical changes to the core of Java EE.  These changes have continued in the latest iteration, Java EE 6.

Interested in comparing Java EE 6 to my experiences with Spring and Hibernate, I picked up a book on the topic and began playing around with some code.  It was easy to see the influence of Spring and Hibernate in components such as JPA, Java EE’s ORM solution; a dependency injection component; and a focus on using POJOs.  The purpose of this article will be to give a brief overview of the core Java EE 6 technologies.

Java Persistence API

The Java Persistence API (JPA) is Java EE’s ORM solution.  It is meant to be a replacement for EJB Entity Beans, which have been deprecated in Java EE 6.  If you are familiar with Hibernate, then you will feel right at home with JPA.  In fact, many Hibernate developers played a role in the design and development of JPA.  For those of you unfamiliar with Object-Relational Mapping (ORM); it is a technique used to map your programs domain objects to the tables of your database.  ORMs usually make it very easy to perform CRUD operations on your data as well provide you with methods to query the underlying database using your object model rather than a standard SQL query.  ORMs commonly abstract away the underlying database and present a clean, cross-database API for accessing data.  JPA, like the latest versions of Hibernate, allow two methods of mapping your classes to the database: XML and annotations.  Following the trends of the day, use of annotations is encouraged over XML, but both are fully supported.  Using JPA is easy.  You only have to create a single, simple XML file containing database connection information, place the appropriate JPA annotations on your, and then you are ready to go!

Enterprise JavaBeans

Enterprise JavaBeans (EJB) is Java EE’s business layer solution.  The EJBs are where you will place most of your business logic.  The EJB engine will take care of many cross cutting concerns such as transactions and security for you.  EJB was heavily frowned upon in previous versions for being very heavy-weight and complicated.  Starting with version 3, EJB received a complete makeover.  It is now much more lightweight.  You can work almost entirely with POJOs and no longer need to inherit from EJB classes.  Like the rest of Java EE 6, EJB uses convention over configuration so the very little configuration you do have to do can be done using simple annotations.  There are two main types of EJB: Session Beans and Message Driven Beans.

Session Beans themselves can be classified into three types: Stateless, Stateful, and Singleton.  Stateless session beans are great for functionality that does not need to maintain state.  For example, a bean that simply queries the database to received the latest news updates can be stateless.  Because state does not need to be maintained, stateless beans can be kept in a pool and reused for multiple requests.  Stateful Beans are good for situations where you need to maintain state, such as keeping track of a customers shopping cart.  Stateful beans stay alive for the duration of the session.  Finally, Singleton Beans can be used for logic that you want to have available globally.  Only a single copy of Singleton bean is created and it is shared by all requests.

Message Driven Beans (MDB) are used to receive messages from Java Message Service (JMS).  An MDB can subscribe to messaging queues and can act on messages that appear in the queue.

JavaServer Faces

JavaServer Faces (JSF) is Java EE’s presentation technology.  It is similar to ASP.NET Web Forms in that it uses controls, called components in JSF, that emit HTML code.  Unlike ASP.NET Web Forms, however, JSF is an MVC framework.  Previous versions of JSF used JSPs as the view engine.  In Java EE 6, Facelets are the default view engine.  Unlike JSPs, Facelets are valid XML files that work a lot better with the JSF component model.  The model can be accessed through something called a managed bean.  A managed bean is a simple POJO that is annotated as a managed bean.  The properties of the managed bean can be used directly in the facelet and can be bound to the components.

Other Changes

The latest version of Java EE also provides dependency injection functionality.  This makes your application more loosely coupled and also helps make unit testing easier.  As mentioned earlier, Java EE 6 favors the use of annotations over XML configuration.  The people who complained of “XML Hell” in previous versions of Java EE can breathe a sigh of relief.  Convention over configuration has also taken a hold in the Java EE world.  Instead of having developers create a ton of configuration, Java EE will default to using reasonable defaults and allow for configuration when you wish to override the defaults.  This combined with the use of annotations over XML allows you to hit the ground running with Java EE faster than ever before!

Conclusion

Overall, I feel that Java EE 6 is a huge step in the right direction.  I think JPA is great and very comparable to Hibernate.  EJB has been improved a lot and is now much easier to use.  As far as JSF goes, I prefer to use a framework like Spring MVC with JSPs as the view engine.  I think that the JSP view engine is very powerful and I like working close to the HTML rather than abstracting it away.  Others may definitely enjoy the power of JSF though.  I feel that dependency injection in Java EE is a little lacking compared to what is available in Spring.  I would say that if you are working on an existing project using Spring or another third party framework, you probably shouldn’t bother changing over to Java EE 6.  However, if you are starting out on a new project, I would take a look at Java EE 6.  It is powerful and much easier to use now, having learned a lot from frameworks like Spring and Hibernate.

Want to learn more?

I recommend the book Beginning Java EE 6 Platform with Glassfish 3 by Antonio Goncalves.  It is well written and gives a great overview of development with Java EE 6.

-Dylan

The Unstandard Tag Library is a JSP tag library that was developed as part of the Jakarta Project. Its purpose is to provide a collection of useful tags that people have been requesting for JSTL. The library serves as a place to keep all of these tags until they are officially added to the Standard Tag Library. This article focuses on the use of one of the tags contained within the library, the useConstants tag.

The Problem

While working on a project for a client, I realized that they were using a Java class with constants to define strings used within the application. The idea was to use the constants everywhere in the application where the strings were needed so they could easily be maintained in one location without having to search through the whole application when making a change. This makes sense, and is a common best practice. I was working on a JSP page that needed to use the constants from the class. It is now considered bad practice to use Java Scriptlets in your JSP page. It is much better to use the Expression Language (EL) in combination with JSTL and other custom tags. Trying to keep to this rule I quickly ran into a problem. The EL does not allow and easy way to access constants from a Java class. That is where the Unstandard Tag Library’s useConstants tag comes in handy.

How To Use It

Once you have added the library to your project it is very simple to use. Let’s assume we have a java class containing constants such as the one below:

package com.tallan.unstandard;  

public class MyConstants {    

  public static final String MY_CONSTANT_1 = 'Hello World';
  public static final String MY_CONSTANT_2 = 'Goodbye World';  

}

Let’s also assume that we added the tag library to our page as follows:

<%@ taglib uri="http://jakarta.apache.org/taglibs/unstandard-1.0"
           prefix="un"%>

We can then utilize the useConstants tag as follows:

<un:useConstants var="Constants"
                 className="com.tallan.unstandard.MyConstants" />

After we run this line of code, an object called Constants will be available for use on the page. We can use it with the EL and access the constants as properties of the object. For example:

<p>${Constants.MY_CONSTANT_1}</p>

This solves our problem of using constants from a Java class within a JSP page without relying on scriptlets.

Where To Get It

You may be thinking “This is great, but where can I find this library?” Unfortunately the Jakarta project has stopped development of the library and no longer makes it obvious where you can get the code. If you look around on the Jakarta site you will find that they allow you to get the project out of source control and build it with Maven, but this is a little bit of a hassle. If you want an easier way to get the library just go here. This site contains old binaries of the library and they should work just fine.

Conclusion

The Unstandard Tag Library contains many useful tags that can help in the development of our JSP pages. While it is no longer being actively developed, it can still be a very useful tool. We covered how to access constants from a Java class using the library’s useConstants tag.

Want to Learn More?

If you want to learn more about the tags available in the Unstandard Tag Library and how to use them, then head over to the documentation page for the library located here.

In C++,

#include <stdio.h>
void swapnum(int &i, int &j)
{
     int temp = i;
     i = j;
     j =  temp;
} 

int main(void)
{
     int a = 10;
     int b = 20;
     swapnum(a, b);
     printf("A is %d and B is %d\n", a, b);
     return  0;
}

In C#,

int a = 1;
modify(ref a); //now a=2
void modify(ref int a)
{
     a = 2;
}

In Java, however, there’s no such thing as pass by reference. Even the so-called pointers (created by ‘new’ operator) are passed by copy of the reference.

Thus, if you do the following,

String a = "a";
modify(a); //a doesn't change, since a is being passed as  a copy of the pointer a.
void modify(String a)
{
     a = "b"
     //this a  is a different pointer, thus does not affect the real 'a' pointer outside of the  method.
}

As you can see, there’s no direct way of modifying the variable. This has become a problem for me in many cases, since from time to time, it is necessary to have direct access to the variables.

The answer is by using a wrapper.

Here’s an example.

String a = "a";
System.out.println(a); // 'a' gets printed
String[]  array = new String[]{a}; //add a copy of the pointer variable a to String  array
modify(array);
System.out.println(array[0]);

void modify(String[] array)
{
     array[0] = "b";
}

This is not the most elegant way of doing it, but you get the idea.

One thing to remember is that String[] array contains a copy of pointer ‘a’. When you assign, or add, items to any collections such as array, you’re passing a copy of a pointer. So the variable ‘a’ in the example above still is pointing to the value ‘a’, whereas array[0] points to ‘b’. In order to finalize the pointer modification, you need to assign

a = array[0].

So, the basic idea is this: In Java, when you pass variables around, whether they are pointers or primitive values, you’re always dealing with a copy of the variables, not the variables themselves. If you understand the basic idea of it, you can take advantage of the true “Pass by Reference”.

I hope this sort of ‘trick/hack’ can be of help to you all.

-Seung Kim (SK)