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)

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.

public class Test {
public static void main(String[] args) {
String a = “a”;
System.out.println(a); // ‘a’ gets printed
String[] array = new String[]{a}; //adds a copy of pointer ‘a’ to String array
modify(array);
System.out.println(array[0]);
}
public static void modify(String[] array) {
array[0] = “b”;  //instantiating a new object ‘b’ to the copy of variable a
}
}

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)

Since my current project utilizes spring and aop, I thought it would be a great idea to utilize AOP to cache data.

I actually wrote a prototype file and it was a very rudimentary yet working prototype.  However, I soon realized that Springmodules already created such feature, and it toally is a great feature to use.

Using simple AOP concept, you intercept the method call and using method parameters as HashKeyGenerator input values, the Springmodules’s cache simply get/put data from/into cache storage.  Currently, I configured it to using OSCache for its native support by Springmodule Cache Provider.

https://springmodules.dev.java.net/docs/reference/0.8/html/cache.html

I believe as the frameworks such as Spring evolves, developers can truly focus on their logic and development without worries of logging, security, cache, and any other cross-cutting concerns.  AOP is truly revolutionlizing the software development industry.  I am very glad to see it happening.

Good news for .NET community is that spring.net also supports AOP based Cache.

http://springframework.net/doc-latest/reference/html/aop-aspect-library.html

I think more and more developers should know of these great features that tremendously can help build great applications without any of the boiler-plate code.  AOP, IoC, ORM and other evolving industry standards truly the great assets that every developer should be aware of when developing/architecturing applications.

-Seung Kim (SK)

 I did a bit of google search, and it turns out that when saving an object, I needed to make sure the object was attached to Hibernate session.

This can be very tedious issue, since that means if you need to save an object that is not attached to a session, you need to do these.

1. Retrieve the object using the Id value found within the object passed to you.
2. Update the property values one by one
3. Save the object back within the same Hibernate Session

Here’s a quick summary that I found out about MERGE and SaveOrUpdate.

void saveOrUpdate(object)->object must be attached to a hibernate session (including all sub objects within the object), and once save/update is done, the object reflects the updated changes (e.g. primary key if saving a new object)
�
Object merge(object)-> object does not have to be attached to a hibernate session.  Once save/update is done, the object DOES NOT reflect the change.  The returned object reflects the changes, and it is attached to hibernate session.

MERGE method offers greater flexibility when it comes to saving data objects, since you need not worry about attaching object to Session.
You can create an object, set Id, and other properties on your own, and save it without worrying about the Hibernate Session exception.
If you’re using saveOrUpdate, the object saved MUST be attached to session.  I believe many people have experienced this issue.
�
This means you can create a copy of object from Service layer and just pass the object to your DAO.  Hibernate takes care of MERGING the data to appropriate hibernate session attached object and saves the data.

The only downside of using MERGE is that the object passed does not reflect the changed information.  So, if you need to use the updated object, you must get it from the returned object, not the parameter object.

I hope this helps.

-SK

http://icedjava.blogspot.com/2007/12/dear-java-thanks-for-complexity-of.html

There is an interesting link from this blog posting. I have not read it in depth. It looked good on an initial skim. The author seems to be trying to be objective, rather than selling one framework over another. (Go past the pictures of his family… would be interesting to hear the presentation that goes along with this PDF):

Comparison of frameworks:
https://equinox.dev.java.net/framework-comparison/WebFrameworks.pdf

I am interested in hearing others point of view on this (not looking to start a flame war but a skirmish maybe interesting ).

Thanks,

Kim Stevens

(Originally posted: 12/20/07)

(from the mySQL manual)

For beginners, a useful startup option is --safe-updates (or --i-am-a-dummy, which has the same effect). This option was introduced in MySQL 3.23.11. It is helpful for cases when you might have issued a DELETE FROM tbl_name statement but forgotten the WHERE clause. Normally, such a statement deletes all rows from the table. With --safe-updates, you can delete rows only by specifying the key values that identify them. This helps prevent accidents.

When you use the --safe-updates option, mysql issues the following statement when it connects to the MySQL server:

SET SQL_SAFE_UPDATES=1,SQL_SELECT_LIMIT=1000, SQL_MAX_JOIN_SIZE=1000000;

See Section 12.5.3, “SET Syntax”.

The SET statement has the following effects:

• You are not allowed to execute an UPDATE or DELETE statement unless you specify a key constraint in the WHERE clause or provide a LIMIT clause (or both). For example:

  UPDATE tbl_name SET not_key_column=val WHERE key_column=val;
  
  UPDATE tbl_name SET not_key_column=val LIMIT 1;

• The server limits all large SELECT results to 1,000 rows unless the statement includes a LIMIT clause.
• The server aborts multiple-table SELECT statements that probably need to examine more than 1,000,000 row combinations.

To specify limits different from 1,000 and 1,000,000, you can override the defaults by using the --select_limit and --max_join_size options:

I’ve used JCoverage in the past and while it’s HTML based reports are useful for project managers they are less so for developers. This tool essentially gives you the same information, but directly in Eclipse. You simply run the analyzer on either a single class or a set of classes and viola… you have your coverage report.

It even color codes each line of code within your editor window.

Use the http://update.eclemma.org/ update site to install EclEmma.