Enterprise Java In Action

Multithreaded Testing

2008-09-10T11:00:00.001-07:00

Every now and then you’ll work on something that needs to handle requests from multiple concurrent threads in a special way. I say “special way” because in a web application, everything needs to handle being executed concurrently and there are a slew of techniques used to handle this (prototypes, thread locals, stateless services, etc). Here’s an example of what I mean by “special”…

On my current project, we have a queue of articles that need human-user attention (i.e. editorial moderation). Each article must be doled out to only one moderator and there are multiple instances of the web application servicing requests in the cluster. Imagine tens of thousands of articles per day and a team of moderators churning through them. We can’t rely on Java synchronization because it only works within the JVM instance, not across server instances.

The simplified version of the service interface we’re working on looks like this:

ArticleService.java - Example service interface

public interface ArticleService
{
    Article findNextArticleForModeration();
}

What makes this interesting is that we must ensure that the service doesn’t hand out the same Article to more than one user. This is impossible to assert using a single thread. We’ve all been told that multiple threads and automated testing don’t mix. It’s generally true and should be avoided if at all possible, but in some cases it’s the only way we can truly assert specific behavior. I’ve found a pretty simple way to do this type of testing in a reliable, consistent, and non-disruptive manner. Despite the fact that the technique leverages Java 1.5 built-in concurrency utilities, most of the engineers who have seen it are surprised and weren’t aware that such testing was so easy to implement.

Given the above service interface, here’s a test that will assert that no single article is given out to more than one invoker of the method findNextArticleForModeration(). The scenario we’re simulating is 10 users feverishly moderating a queue of 250 articles as quickly as possible.

ArticleServiceImplTest.java - Test to invoke service concurrently

...
public void findNextArticleForModerationStressTest() throws Exception
{
    final int ARTICLE_COUNT = 250;
    final int THREAD_COUNT = 10;   // Create test data and callable tasks
    //
    Set<Article> testArticles = new HashSet<Article>();   Collection<Callable<Article>> tasks = new ArrayList<Callable<Article>>();
    for (int i = 0; i < ARTICLE_COUNT; i++)
    {
        // Test data
        testArticles.add(new Article());   // Tasks - each task makes exactly one service invocation.
        tasks.add(new Callable<Article>()
        {
            public Article call() throws Exception
            {
                return articleService.findNextArticleForModeration();
            }
        });
    }
    articleService.createArticles(testArticles);   // Execute tasks
    //
    ExecutorService executorService = Executors.newFixedThreadPool(THREAD_COUNT);
    // invokeAll() blocks until all tasks have run...
    List<Future<Article>> futures = executorService.invokeAll(tasks);
    assertThat(futures.size(), is(ARTICLE_COUNT));   // Assertions
    //
    Set<Long> articleIds = new HashSet<Long>(ARTICLE_COUNT);
    for (Future<Article> future : futures)
    {
        // get() will throw an exception if an exception was thrown by the service.
        Article article = future.get();
        // Did we get an article?
        assertThat(article, not(nullValue()));
        // Did the service lock the article before returning?
        assertThat(article.isLocked(), is(true));
        // Is the article id unique (see Set.add() javadoc)?
        assertThat(articleIds.add(article.getId()), is(true));
    }
    // Did we get the right number of article ids?
    assertThat(articleIds.size(), is(ARTICLE_COUNT));
}
...

The test starts off by creating 250 test articles to be moderated. It also creates 250 ‘tasks’, each designed to make a single service invocation of findNextArticleForModeration(). The real magic happens in Executors.newFixedThreadPool() and executorService.invokeAll(). The first creates a new ExecutorService backed by a thread pool of the specified size. This is a generic ExecutorService that is designed to churn through tasks using all of the threads in the pool. invokeAll blocks until every task has finished executing. In this test, 10 threads will rip through 250 tasks, each making a single call to our service and capturing the result of that call. Each task execution results in a Future, which is a handle to the results of the task (and more).

Iterating over each resulting future, we make several assertions. The most important one is the last, where we assert that every task is given a unique Article. Thanks to the natural semantics of Set, this is easy to do in an elegant way. Another useful, though unexpected, feature is that if an exception occurs during the task execution, an ExecutionException will be thrown when get() is called on the corresponding Future. If our service fails for some reason, the test will fail because no exceptions are expected.

This technique makes simulating a multi-threaded environment in a test easy and readable. It’s important to only use this technique when it’s really necessary. The resulting test is more of an integration test than a unit test, and its run time is orders of magnitude more than a unit test, so overuse of the technique will artificially inflate the time it takes to runs the tests. After I’ve finished working on the component under test, I will reduce the test-data size and thread count to a level that the test still provides value, but is no longer a stress test (e.g. 10 articles and 2 threads). The next time the component is being worked on, the developer can crank up the values and run the tests to be confident that the behavior isn’t broken.

The complete source for a working example of this technique is available here. You’ll need Maven (or IntelliJ IDEA 7.x) to build and run the test. By default, the tests run against an in-memory H2Database instance, but if you look at application.properties you’ll see configurations for PostgreSQL and MySQL as well.

Happy testing!

by christian

Launching system processes from Java applications

2008-09-08T14:07:00.001-07:00

Are you tired of issues with Runtime.getRuntime().exec()? I was!

So I decided to create a small library to handle all the issues. Once and for all.

Main features

It's easy to redirect stdin, stderr and stdout to appropriate Java Input and Output streams, so you can now embed operating-system processes inside your applications.
It's very easy to cancel a running process, by using the Future<Integer> interface.
Automatically handles pipipng process streams into Java streams (and viceversa).
Runs well in Linux and Windows. Probably runs well in Solaris and MacOSX too (haven't tried yet though)
You can specify a working directory for the running process.
Very small library (just one final class and two interfaces).

Sources and binaries are available in my attic, of course.

What for?

This small library will allow me to embed Scheme interpreters such as guile or scm or mzscheme inside the Scheme IDE I'm building on top of the NetBeans Platform.

How to use?

You can see the Javadoc. Basic usage is as follows:

// Obtain a process executor
ProcessExecutor executor =
   ProcessExecutorFactory.getDefault();

// Launch the process
Future<Integer> process = executor.execute(
   ProcessInputOutput.DEFAULT, null, "/bin/ls -ali");

// If you want to kill the process write:
process.cancel( true );


// To get the exit status of the process use:
System.out.println( process.get() );

Now, that's easy, isn't it?

What next?

As usual I'll do some more extra testing and, who knows, maybe this could be integrated in NetBeans in the future!

All bugs and enhancements are, of course, welcome. Please send me an email or add a comment to this entry.

Happy processing,

Antonio

GridGain - simple, effective, and made of pure happy juice

2008-09-06T10:24:00.001-07:00

Let's talk about real, tangible, hype-less, grid computing. I swear, it's real.

I've heard endless sales pitches about moving your apps to the grid. It's almost quaint how easy they make it sound. Let's pretend, for a moment, you have an application that benefits from parallelization, you have no issues with data availability, and you control your source code (because you're not going to make every application you use magically run in parallel regardless of the sales pitch).

To this end, I've been using GridGain, recently. In a few weeks I might even be able to talk about why, but that's far less important. For those living under a rock, GridGain is a Java implementation of a Google-ish map / reduce system. The effect is that, with very little code and even less configuration, one can cause suitable code to run in parallel, on a grid of JVM nodes. I won't discuss the map / reduce concept in detail, other than to say the idea is to:

take a job, break it up into smaller units of work
assign these units to processing nodes
collect the results from the processing nodes
aggregate the results, as appropriate

Items #1 and #2 refer to the map part of the process, while #3 and #4 refer to the reduce component.

There are two ways to use GridGain. The first method is to annotate methods (either static or otherwise) that should be run on the grid. This is fast to write, and coarse-grained in that the unit of work is (usually, but need not be) the entire method. The second method of running tasks on the grid is by directly accessing the GridGain APIs. This, of course, tends to mean a bit more code, but to some, may be easier to understand and debug. Which method you choose, will probably depend mostly on preference, but could also be influenced by dependencies. I opted for direct invocation via the APIs because I prefer not to futz around with AspectJ - which is how the annotations actually work - and friends unless I'm also using it for other things. GridGain is happy to work with AspectJ, Spring AOP, or JBoss AOP, according to the docs, although they seem to recommend against Spring AOP due to a lack of full functionality or some such. I didn't get too much into the details.

The APIs are surprisingly direct and simple to understand for something that is so seemingly nebulous. This, coupled with some of the best documentation I've seen in some time, makes for a pleasant experience. The only thing that makes my vision a little blurry is the generic-soup that begins to occur, but for the type safety, it's probably worth it; anything that needs to run on a grid is arguably important enough that you can groan through the angle brackets.

Running a GridGain node requires zero configuration, in many cases, although being a Spring application, itself, and being well written with a number of service provider interfaces, one could easily sculpt what amounts to a custom product out of it. What is nice is that one can easily run GridGain within an IDE like Eclipse during testing and development, which significantly speeds the process of rolling out your apps. While on the topic of time saving features, GridGain using peer-based class loading meaning, for simple, self contained, tasks, one need not do any kind of special deployment to execute tasks. The task classes are transmitted and loaded by GridGain itself, without any need for restarts or copying. It's like a magic fairy sprinkled happy-time sparkles in my brain.

Of course, GridGain provides all manners of fancy pants things that I haven't yet explored such as node affinity for processing close to your data, integration with caching products from Oracle and JBoss, different scheduling and communication methods, and similar goodies. I also haven't fully explored implementing custom service providers, but it's mostly because I couldn't find one that I might need that wasn't already implemented.

Here's a bottom of the barrel, super-contrived, example to whet your noggin knobs.

public class TestApp {

  static public void main(String[] args) throws GridException {
    try {
      Grid grid;
      GridTaskFuture future;

      grid = GridFactory.start();

      future = grid.execute(MyTask.class, "Print me...");

      // This causes GridGain to block until all jobs are complete. It
      // also returns the result, if there is one.
      future.get();

    } finally {
      GridFactory.stop(false);
    }
  }
}

/*
 * The task class is going to be the unit of word that gets split
 * into smaller jobs (GridJob) that get distributed and executed.
 * I'm using adapters for both the task as well as the jobs to avoid
 * extra work, so yes, I'm cheating.
 */
public class MyTask extends GridTaskAdapter<String, String> {

  @Override
  protected Collection<? extends GridJob> split(int gridSize, String arg)
    throws GridException {

    List<GridJobAdapter<String>> jobs;

    jobs = new ArrayList<GridJobAdapter<String>>();

    // Build a collection of jobs to run on the grid.

    for (int i = 0; i < 10; i++) {
      jobs.add(new GridJobAdapter<String>(arg) {
        @Override
        public Serializable execute() throw GridException {
          System.out.println("arg:" + getArgument());
        }
      });
    }

    return jobs;
  }


  @Override
  public String reduce(List<GridJobResult> results) throws GridException {
    System.out.println("Not much to reduce when we're printing stuff...");

    return null;
  }
}

I know it's probably considered verbose, still, to the scripting community at large, but when you consider what's happening here, it's pretty bad ass.

It's worth noting that there are other frameworks similar to GridGain, in this space, that deserve a look as well. Hadoop comes to mind. I have no direct experience with them, so I don't want to say either way, but I have heard nice things.

This is all very contrived and still thin on details. My goal wasn't to reproduce a howto, but more so to, well, to glow about GridGain, to some small degree. I encourage everyone to check out GridGain for themselves and find the things relevant to them.

by E. Sammer

Improve your unit-tests with jMock2

2008-09-06T10:19:00.001-07:00

Writing unit-tests should be part of your development process whether you write them before or after the actual coding I leave that up to you. On of the pitfalls of writing unit tests is that the units become to big.

The unit your are testing, a method in most cases probably uses some other beans or services to do its job. In your unit test you don’t want to test those other beans but just your method. Because you use decoupling you can easily override the interfaces of the services in your test case and inject those services in your instance you are testing. This is an example of a mock object.

This is maybe good for one or two mock objects but it gets tricky. Who test the mock objects? You will soon get a lot of logic in the mock objects. To reuse them they need to be extracted from the unit test. You don’t have checks if the mock objects are really called. There are several frameworks that will do this mocking for you. You supply them the interface and they will give you an implementation which can be injected into the bean thats being tested.

Recently (14 jul 2008) jMock has released their 2.5.0 version of the lightweight mock framework. In the next example I shortly demonstrate how jMock2 can be used to improve your unit test.

In the example I want to test the registerUser method on the RegistrationBean. The bean will only create a new user if the username and password are not blank (they must contain a non white space character). The method will return true if the user is created otherwise false. The method uses to other references. The references need to be mocked out in the unit test.

@Stateless public class RegistrationBean implements RegistrationLocal { @EJB private NotificationMailerLocal notificationMailerBean; @PersistenceContext private EntityManager em; public boolean registerUser(String username, String passwd) { if (StringUtils.isNotBlank(username) && StringUtils.isNotBlank(passwd)) { User user = new User(username, passwd); em.persist(user); notificationMailerBean.mailNewRegistration(user); return true; } return false; } … }

I use the Junit4 framework to write the tests.
To tell Junit4 I use jMock the @RunWith is added on top of the test class. The test checks if a user is created when a non blank username and password is supplied. jMock uses expectations. If you don’t add them and the mocked object is called the test will fail. With expectations we can tell jMock that we expect that a mocked method is called exactly once or we don’t care. There are many more expectations you can add.
But in this example we expect that the notification mail is send exactly once with a non null user object. We also tell Jmock that we are not interested in the calls to the em mock object.

@RunWith(JMock.class) public class RegistrationBeanTest { Mockery mockContext = new JUnit4Mockery(); @Test public void registerUser() { final NotificationMailerLocal mailer = mockContext .mock(NotificationMailerLocal.class); final EntityManager em = mockContext.mock(EntityManager.class); mockContext.checking(new Expectations() { { ignoring(em); one(mailer).mailNewRegistration(with(aNonNull(User.class))); } }); RegistrationBean regBean = new RegistrationBean(); regBean.setNotificationmailer(mailer); regBean.setEntityManager(em); assertTrue(regBean.registerUser("TestUser", "qwerty")); } … }

In the second test I want to test that the user is not created when we supply an empty string as password. The registerUser method should return false. But I also want to make sure that the registration mail is not sent.

@Test public void registerInvalidUser() { final NotificationMailerLocal mailer = mockContext .mock(NotificationMailerLocal.class); final EntityManager em = mockContext.mock(EntityManager.class); mockContext.checking(new Expectations() { { never(em); never(mailer); } }); RegistrationBean regBean = new RegistrationBean(); regBean.setNotificationmailer(mailer); regBean.setEntityManager(em); assertFalse(regBean.registerUser("TestUser", "")); }

Another problem I often have with mock objects is how to tell the mocked object what it should return. For this I changed the check in the registrationBean a little. It now uses a other bean that checks if the password is strong enough.

if (StringUtils.isNotBlank(username) && passwordCheckerBean.checkPass(passwd)) { … }

In the test we now also need a mock object for the passwordCheckerBean. But this time the mocked object should return a value. With Jmock you can also express this in a Expectation. The expectations part says that the checkPass method on the passChecker mock object is called only once with any String object. If it is called it will return true.

… final PasswordCheckerLocal passChecker = mockContext.mock(PasswordCheckerLocal.class); mockContext.checking(new Expectations() { { … one(passChecker).checkPass(with(any(String.class))); will(returnValue(true)); } }); … regBean.setPasswordChecker(passChecker); …

For more about adding expectations to your mock objects go to the http://www.jmock.org site.
They have a quick getting started but also an useful cheat sheet http://www.jmock.org/cheat-sheet.html.

by Alan van Dam

Optimize your java applications synchronization-instantiation-casting-exceptions-and-threads

2008-05-29T12:50:00.001-07:00

Method Call Optimization: There are two basic categories of methods: those that can be statically resolved by the compiler and the rest, which must be dynamically resolved at run time. To statically resolve a method, the compiler must be able to determine absolutely which method should be invoked. Methods declared as static, private, and final, as well as all constructors, may be resolved at compile time because the class to which the method belongs to is known. A statically resolved method executes more quickly than a dynamically resolved method because, statically resolved method, the binding is done by the compiler and for other methods the binding should happen at runtime depending on the object instance that is being refered.

Even for a statically resolved methods, there will be considerable execution overhead – the local variables should be saved, the method arguments should be pushed to the stack. So it is better to eliminate small methods if there is only one caller. You may not be able to eliminate method calls in your code, but you can at least minimize the method calls at the bytecode level by inline the methods. You can instruct the compiler to inline small methods by using the –O flag.

Inlining a method call inserts the code for the method directly into the code making the method call. This eliminates the overhead of the method call. For a small method this overhead can represent a significant percentage of its execution time. Note that only methods declared as either private, static, or final can be considered for inlining, because only these methods are statically resolved by the compiler. Also, synchronized methods won't be inlined. The compiler will only inline small methods typically consisting of only one or two lines of code.

Warning: Please do not use the inlining option if you are using the 1.0 version of javac compiler because it has a bug that may generate byte code that can't pass the bytecode verifier when the -O option is use. This bug has been fixed in JDK 1.1 onwards.

The next best option is to convert method and especially interface invocations to static, private, or final calls. If you have methods in your class that don't make use of instance variables or call other instance methods, they can be declared static. If a method doesn't need to be overridden, it can be declared final. And methods that shouldn't be called from outside the class should always be declared private anyway.

Minimize Synchronization: Call to a synchronized method is very expensive, in fast it is the most expensive method call. Not only does it involve getting the lock on an object’s monitor but, but there is always the potential that the call will be delayed waiting for the monitor for the object. And when the method returns, the monitor must be released, which takes more time.

So, it is always better to reduce usage of synchronized methods and blocks as far as possible, so make sure that the operations actually require synchronization. Be careful though; this is not an area of your program to be overly ambitious in optimizing as the problems you can cause can be difficult to track down.

Also, you must try to use synchronized methods in place of synchronized blocks as far as possible because synchronized method invocation is slightly faster than entering a synchronized block as synchronized method invocation is handled differently in the byte code.

Also, a call to a synchronized method when the monitor is already owned by the thread executes somewhat faster than the synchronized method when the monitor isn't owned. So, If you have a heavily synchronized class that is calling lots of synchronized methods from other synchronized methods, you may want to consider having a few synchronized methods delegate the work to private non-synchronized methods to avoid the overhead of reacquiring the monitor.

Save Casting: Casting object references to refer to different object types in Java (object casts) can get pretty dense -- especially if you work with a lot of lists or other collection classes. It turns out that any object cast that can't be resolved at compile time is so expensive that that it is better to save the cast object in a local variable than to repeat the cast.

So instead of writing:

boolean equals (Object obj) {
if (obj instanceof Rectangle)
return (((Rectangle)obj).x == this.x && ((Rectangle)obj).y == this.y && ((Rectangle)obj).width == this.width && ((Rectangle)obj).height == this.height);
return false;
}

Do the casting only once:

boolean equals (Object obj) {
if (obj instanceof Rectangle) {
Rectangle rect = (Rectangle)obj;
return (rect.x == this.x && rect.y == this.y && rect.width == this.width && rect.height == this.height);
}
return false;
}
If the cast is to an interface, it's probably twice slower than casting to a class.
In fact, there is one type of cast that can take much longer to execute. If you have an object hierarchy like
interface I {}
class Super {}
class Sub extends Super implements I {}
then the following cast, to an interface implemented by a subclass, takes anywhere from two to three times as long as casting to the subclass.
Super su = new Sub();
I i = (I) su;
The further the separation between the interface and the subclass (that is, the further back in the interface inheritance chain the cast interface is from the implemented interface), the longer the cast takes to resolve.
Also beware of unnecessary uses of instanceof. The following cast is resolved by the compiler and produces no runtime code to implement the unnecessary cast.

Rectangle q = new Rectangle ();
Rectangle p = (Rectangle) q;
However,
Rectangle p = new Rectangle ();
boolean b = (p instanceof Rectangle);
cannot be resolved by the compiler because instanceof must return false if p == null.

Casting data types is simpler and cheaper than casting objects because the type of the data value being cast is known (for example, an int never is actually a subclass of an int.) However, again since int is the natural size used by the JVM (ints are the common data type that all other data types can be directly converted to and from), beware of using the other data types. Casting from a long to a short requires first casting from a long to an int and then from an int to a short.

Reuse Object Instances: Creating an object is fairly expensive in terms of CPU cycles. On top of that, discarded objects will need to be garbage collected at some point. It takes about as long to garbage collect an object as it takes to create one.
Also, the longer the hierarchy chain for the object, the more constructors that must be called. This adds to the instantiation overhead. If you add extra layers to your class hierarchy for increased abstraction, you'll also increase the instantiation time.
The best option is to avoid instantiating objects in tight loops. Where possible, reuse an existing object.
The loop
for (int i = 0; i < limit; i++) {
ArrayList list = new ArrayList();
// do something with list...
}
would be faster if written as
ArrayList list = new ArrayList();
for (int i = 0; i < limit; i++) {
list.clear();
// do something with list...
}

Also, it is better not to explicitly initialize instance variables to their default values because when an objects is created all instance variables will by virtue get initialized to the default values. If you are explicitly doing the same, it will duplicate the default initialization, generate additional bytecodes, and make the instantiation take longer. (There are rare cases when the explicit initialization is needed to reinitialize a variable that was altered from the default value during the super class's constructor.)

Optimizing Exception Handling: The try/catch/finally mechanism is implemented efficiently in the JVM. When an exception is thrown, only a quick check is done against the exception table for each method in the call chain to determine whether or not the exception is handled by the method.
Also, a try {} statement is cheap, no much bytecodes are generated, all that try {} statement adds to your code as far as overhead is the goto bytecode to skip the catch () {} statement and one or more entries in the method's exception table. A finally statement adds a little more overhead as it is implemented as an inline subroutine.

However, instantiating a new exception can be expensive. An exception generates and stores a snapshot of the stack at the time the exception was instantiated. This is where most of the time for instantiating an exception goes. If you're throwing exceptions regularly as part of the normal operation of your code, you may want to rethink your design.

But, if you do have a need to do this (such as returning a result from several calls deep), and if you're simply going to catch and handle the exception, then repeatedly instantiating an exception can be a waste of time. Instead, it is possible to reuse an exception. That is when you are not concerned with logging the exception, but you are only interested in returning a result from several calls deep, then you can have the exception as a class variable and always change the required values in the exception and throw the reused exception.

Reduce Threads: Using threads can cause problems memory wise and also CPU cycle wise. Each running thread has both a native/"C" stack and a Java stack which will take some memory. There is also an overhead for switching between threads (a context switch), which varies significantly between platforms. Moreover, if the threads are in some synchronized method or block, then a context switch also involves releasing / acquiring the monitor for an object, so context switch will be much slower when threads are in synchronized methods or blocks.
There are many places in your code where threads can be minimized or avoided. For Example, a java game can be easily implemented by using separate threads for painting, keys handling and AI, In fact, Painting, key handling and AI together can be handled by a single thread make will make the code slightly complex but will avoid the over associated to context switching between threads..

Java Architectural Knowledge for Job Interviews. Are we prepared?

2008-05-25T07:47:00.001-07:00

I already interviewed lots of Java developers during hiring activities. As part of the interview, besides other things, I like to understand if the person being interviewed has understanding of the applications he/she develops as a whole, I mean, not only understands business requirements but also understands the entire architecture of the application and, most important, why that specific architecture is in place for that application and its specific needs.

So below a typical dialog between a candidate (C) and I regarding architecture of a Java EE application.

- So, could you please describe, from your perspective, what should be a typical Java EE architecture for, let's say, a medium-size web-based application?
C - Of course. Well, typically I will have in place a lightweight container like Spring and persistence mechanism like Hibernate. Spring will do everything for me.
- Alright, let me be more specific, I believe my question was not well-built. Imagine if the end user is about to submit a form data. What will be the flow that data would take to be persisted in database? Describe to me the building blocks, all the path of the data, which objects will apply business rules, which objects will handle web requests, etc. Feel free to draw this architecture if you think it is better for you.
C - Not necessary. Well, I would put Spring MVC in place to handle all the requests. For persistence, Spring DAO with Hibernate support.
- hum, I think you haven't got the point. Forget about Spring. forget about EJBs. Forget about lightweight or heavyweight containers. Forget about Hibernate. Imagine you don't have these technologies to assist you. You have to propose the architecture without using any specific product. What would you do? Remember, no products. Just give me building blocks.
C - .....
C - .....
C - In the presentation layer an object will take all data submitted and...
- Which object?
C - hum...... maybe a Servlet object or .....
- Or a managed bean, something like this? Ok, go on. Once data is retrieved from the UI, what will happen?
C - ... ok, data will be sent to an object and this object will perform business rules and after that data will be persisted.
- Could you please be more specific? Do you have in mind any design pattern that could assist you for this architecture? What would be the structure for the domain layer? And Persistence layer?
C - ...
C - Man, I would work with Spring, it does all those things for me.
- Alright, that's good for me. Thank you.

Let me say somethings about this dialog.
First: I don't have any problems with Spring. In one of my posts I said that I never used it because I never had to. We need to find solutions for our problems and not create problems for given solutions. By the way, comments in that post were great.

Second: The candidate never asked how many transactions per minute, hour, etc, how many concurrent users, if it is a critical application. That dictates the architecture. We can't have silver bullet and it seems today most of the "architects" have silver bullets. And, even worst, relying on specific products. Also, based on the non-functional requirements of the application we could see if clustering would be needed. But no, no question about those kinds of things at all.

Third: The lack of knowledge on some typical design patterns is also something to take into account. Façade? DAO? Value Objects? Application Controller? Even if we don't need all of them, candidates should be prepared to use them when necessary.

I know it is hard in an job interview to remember all those things. And I really don't have answers for all problems, most of the times we just can't propose an architecture whitout digging deeper in the details, in the business requirements and having lots of discussions with peers and even business team.
But as developers and architects we can't be relying on specific products, we need to be able to understand architecture as a whole and what are the options we have to better propose a scalable architecture and build a solid system.

Here a few basic references about all this stuff.

Java BluePrints - Here some good stuff for JAva Enterprise Applications.
Java EE Design Patterns: Core J2EE patterns are here also
Patterns of Enterprise Application Architecture, from Martin Fowler.
Head First Design Patterns.

There are lots of other good books and articles. Please, feel free to comment here adding more references.
Also, what do you think would be the basic understanding developers should have nowadays? Any other specific skill?

By Giovani Salvador

Layout management, how simple can it be?

2008-05-25T07:46:00.001-07:00

Trying to teach Java to a 14 year old, and after working on some problems such as: Solving a quadratric equation, checking if a number is prime, we have so far changed the data inside the program, recompiled it and ran again....
We are reaching the point where we want to be able to enter the data in a fashionable way! Meaning time to address the "GUI" problem. While it is straightforward to create a frame and add components to it, it is tricky to layout the components inside the frame.
Here are some examples using the layout manager as little as possible (I am keeping this subject for way later...).
In the first example, we simply add some components to the panel used by the frame (FlowLayout is used by default)
In the second example, we use the GridLayout class to order the components.
In the third example, the components in a row are first added to a panel which is then added to the overall panel.

import javax.swing.*;

public class Test {

  public static void main(String[] args) {
    JFrame frame = new JFrame();

    JPanel panel = new JPanel();

    JLabel l = new JLabel("label:");
    JTextField f = new JTextField(10);
    JButton b = new JButton("Calc");

    panel.add(l);
    panel.add(f);
    panel.add(b);

    frame.getContentPane().add(panel);

    frame.setSize(300, 300);
    frame.setVisible(true);

  }

}

import java.awt.*;
import javax.swing.*;

public class Test2 {

  public static void main(String[] args) {
    JFrame frame = new JFrame();

    JPanel panel = new JPanel();
    panel.setLayout(new GridLayout(4,2));

    JLabel l1 = new JLabel("label:");
    JTextField f1 = new JTextField(10);
    panel.add(l1);
    panel.add(f1);

    JLabel l2 = new JLabel("label:");
    JTextField f2 = new JTextField(10);
    panel.add(l2);
    panel.add(f2);

    JLabel l3 = new JLabel("label:");
    JTextField f3 = new JTextField(10);
    panel.add(l3);
    panel.add(f3);

    JButton b = new JButton("Calc");
    panel.add(b);

    frame.getContentPane().add(panel);

    frame.setSize(300, 300);
    frame.setVisible(true);

  }

}

import java.awt.*;
import javax.swing.*;

public class Test3 {

  public static void main(String[] args) {
    JFrame frame = new JFrame();

    JPanel panel = new JPanel();
    panel.setLayout(new GridLayout(4,1));

    JLabel l1 = new JLabel("label:");
    JTextField f1 = new JTextField(10);
    JPanel panel1 = new JPanel();
    panel1.add(l1);
    panel1.add(f1);
    panel.add(panel1);

    JLabel l2 = new JLabel("label:");
    JTextField f2 = new JTextField(10);
    JPanel panel2 = new JPanel();
    panel2.add(l2);
    panel2.add(f2);
    panel.add(panel2);

    JLabel l3 = new JLabel("label:");
    JTextField f3 = new JTextField(10);
    JPanel panel3 = new JPanel();
    panel3.add(l3);
    panel3.add(f3);
    panel.add(panel3);

    JButton b = new JButton("Calc");
    JPanel panel4 = new JPanel();
    panel4.add(b);
    panel.add(panel4);

    frame.getContentPane().add(panel);

    frame.setSize(300, 300);
    frame.setVisible(true);

  }

}

by Pascal Ledru

Lessons Learned From Spring’s @Autowired

2008-05-25T07:42:00.001-07:00

Last November we got Spring 2.5 and with it the possibility to use annotations for dependency injection (DI). Annotations can be used instead or mixed with the classic application context file(s) based on XML.

If you compare the former more complex XML configurations with what you still have to keep, after using annotations, it’s quite amazing how straightforward the XML becomes. For projects with complex DI configurations it is possible to transfer the configuration in steps.

For our ICEfaces Web application e.g. we started with something like this:

<bean id="businessObject"
    class="com.test.BusinessObject"
    scope="session">
    <aop :scoped-proxy/>
    <property name="simpleProperty">
        <value>Hello World</value>
    </property>
</bean>

<bean id="businessObjectAdministration"
    class="com.test.BusinessObjectAdministration"
    scope="session">
    <aop :scoped-proxy/>
    <property name="simpleProperty">
        <value>Hello Administrators</value>
    </property>
</bean>

<bean id="backingBean"
    class="com.test.BackingBean" scope="session">
    <aop :scoped-proxy/>
        <property name="businessObject">
            <ref bean="businessObject" />
        </property>
</bean>

<bean id="backingBeanAdministration"
    class="com.test.BackingBeanAdministration"
    scope="session">
    <aop :scoped-proxy/>
        <property name="businessObjectAdministration">
            <ref bean="businessObjectAdministration" />
        </property>
</bean>

This is pretty verbose. The references can also be written in compact syntax, like this:

<property name="businessObject" ref="businessObject" />

Here are the corresponding classes:

package com.test;
public class BusinessObject {

    String simpleProperty;

    public void setSimpleProperty(String simpleProperty) {
        this.simpleProperty = simpleProperty;
    }
    public String getSimpleProperty() {
        return this.simpleProperty;
    }
}

package com.test;
public class BusinessObjectAdministration extends
    BusinessObject {

}

package com.test;
public class BackingBean {

    BusinessObject businessObject;

    public void setBusinessObject(BusinessObject businessObject) {
        this.businessObject = businessObject;
    }
    public String getBusinessObject() {
        return this.businessObject;
    }
}

package com.test;
public class BackingBeanAdministration {

    BusinessObjectAdministration businessObjectAdministration;

    public void setBusinessObjectAdministration(
        BusinessObjectAdministration businessObjectAdministration) {
        this.businessObjectAdministration = businessObjectAdministration;
    }
    public String getBusinessObjectAdministration() {
        return this.businessObjectAdministration;
    }
}

Each backing bean in this example uses a corresponding business object, whereas BusinessObjectAdministration is a child of BusinessObject.

Adding Annotations

So, what do we have to change to get this annotation stuff working? The reference attributes in the backing beans get an @Autowired. With this a corresponding Spring bean with the same type is searched during the dependency injection. Additionally, we can skip getter and setter for the reference attributes.

public class BackingBean {

    @Autowired
    BusinessObject businessObject;

    ...
}

public class BackingBeanAdministration {

    @Autowired
    BusinessObjectAdministration businessObjectAdministration;

    ...
}

With this we can also skip the corresponding properties in the application context:

<bean id="backingBean"
    class="com.test.BackingBean" scope="session">
    <aop :scoped-proxy/>
</bean>

<bean id="backingBeanAdministration"
    class="com.test.BackingBeanAdministration"
    scope="session">
    <aop :scoped-proxy/>
</bean>

Pretty simple. But, when you deploy this you get an exception. Spring will tell you that it has problems to inject the businessObject reference into backingBean.BusinessObject, because there are two matches. We’ve an inheritance between BusinessObject and BusinessObjectAdministration. So, both are matched in this case.

Matching via type is not the best solution here. But, there’s another annotation that allows to name the Spring bean we wanna be used during the dependency injection, called @Qualifier. It has a parameter, that allows to set the bean’s name.

When we add this to the backing beans everything works fine.

public class BackingBean {

    @Autowired
    @Qualifier("businessObject")
    BusinessObject businessObject;

    ...
}

public class BackingBeanAdministration {

    @Autowired
    @Qualifier("businessObjectAdministration")
    BusinessObjectAdministration businessObjectAdministration;

    ...
}

Hibernate annotation for a Map of some enum type to some primitive type

2008-03-10T15:00:00.001-07:00

Hibernate Annotations are so great, especially together with the Hibernate Tools that allows to generate the whole database (sql table definitions) from your annotated beans.

Right now I mapped the first time a java.util.Map with some enum type as key and a primitive type as value (java.lang.String).

The mapping looks like the following:


    @CollectionOfElements
    @JoinTable( name="my_table" )
    @Cascade(value = org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
    @Enumerated(value=EnumType.STRING)
    @org.hibernate.annotations.MapKey( columns = { @Column( name="my_enum" ) } )
    @Column( name="my_value", length=4000 )
    public Map<MyEnumType, String> getMappedValues() {
        return _mappedValues;
    }

What I was not able to do was to define the type of the value (String) as hibernate type text. This gave the correct table/column definition at build time (hibernate tools), but a ClassCastException at runtime, saying that MyEnumType is not compatible to hibernate’s type text. So I used the length of the @Column annotation as a temporary workaround - I’ll dig into this now or later - or has anybody a clue how to do this?

Using Dynamic Method Invocation to "Script" Java

2008-03-09T13:43:00.001-07:00

Although Java isn't thought of as a dynamic language now a days, what with Ruby and Groovy being all the rage, Java does have support for dynamic features. (See my previous blog post on the subject and the solution I came up with.)

A Use Case for Dynamic Java

Currently I'm wrapping about a hundred EJB 2.1 LocalHome classes in DAO's, and having them transform local EJB entities into POJO's. Much of the code is largely boiler plate. Actually it's mind numbingly boiler plate. Here's a sample of wrapping a finder:

public Endowment findById ( String id ) {
	try {
		// get the local home
		EndowmentLocalHome endowmentLH = EndowmentUtil.getLocalHome ();
		// lookup the entity
		EndowmentLocal endowmentL = endowmentLH.findByPrimaryKey ( id );
		// return the entity
		return createEndowment ( endowmentL );
	} catch ( Exception e ) { throw new VRRemoteException ( e ); }
}

So, five lines of code just to call a finder, then there's the createEndowment() method that actually does the transformation into a POJO. Additionally every method is cluttered with try {} catch {} constructs, further blurring the intent of the code.

By using reflection and dynamic method calls I've been able to reduce the boilerplate to:

public Member findById ( String id ) {
    return (Member) mixin.find ("findById", new Object[] { id } );
}

If by chance my finder returns a Collection, all I need to do is cast the result to Collection.

Each DAO is specific to a "type." Not type as in a Class, but type as in a "business type," ie the snipped deals with the "Endowment" type. For each type there are a number of EJB 2.1 and POJO classes collaborating to make the whole thing work. For the Endowment type the critical classes are:

EndowmentUtil: A utility class for looking up local and remote home interfaces using JNDI. This utility class shields us complete from JNDI. :) This class is generated by XDoclet.

EndowmentLocalHome: The local home for the Endowment EJB.

EndomentLocal: A local EJB entity of an endowment.

EndowmentValue: A value bean representing an endowment. This is generated by XDoclet.

EndowmentDAO: An interface for a persistence agnostic data access object.

EndowmementDAOEjbImpl: An implementation of EndowmentDAO that wraps the EJB 2.1 LocalHome.

Endowment: A POJO in a new clean package that has no connection to our old EJB 2.1/XDoclet code.

The other thing we're doing is making our POJO's transparently navigable, just like JPA entities are when they are managed by an EntityManager. (ie: We can do contactMechanism.getParty().getMember().)

The major issue is that I had repeating patterns like the findById() example above that are the same except that the "type" differed. The convention is the same, over and over. Reflection and my dynamic method calling to the rescue. (NB: This app needs to run on a Java 1.4 server, otherwise I'd have taken a look at generics to solve some of these issues.)

The Solution

Using the findById sample the pattern is easily identifyable:

public Endowment findById ( String id ) {
	try {
		// get the local home
		EndowmentLocalHome endowmentLH = EndowmentUtil.getLocalHome ();
		// lookup the entity
		EndowmentLocal endowmentL = endowmentLH.findByPrimaryKey ( id );
		// return the entity
		return createEndowment ( endowmentL );
	} catch ( Exception e ) { throw new VRRemoteException ( e ); }
}

Simplifying this to pseudo code can help in seeing the pattern:

public #TYPE# findById ( String id ) {
	try {
		// get the local home
		#TYPE#LocalHome localHome = #TYPE#Util.getLocalHome ();
		// lookup the entity
		#TYPE#Local localEjb = localhome.findByPrimaryKey ( id );
		// return the entity
		return create#TYPE# ( localEjb );
	} catch ( Exception e ) { throw new VRRemoteException ( e ); }
}

We can even simplify this further, because the pattern is really the same with any finder. Look up a #TYPE#Util, call getLocalHome() on it, getting a #TYPE#LocalHome, call the finder method and transform the result into a POJO.

public #TYPE# find (Object[] args ) {
	try {
		// get the local home
		#TYPE#LocalHome localHome = #TYPE#Util.getLocalHome ();
		// lookup the entity
		#TYPE#Local localEjb = localhome.find ( args );
		// return the entity
		return create#TYPE# ( localEjb );
	} catch ( Exception e ) { throw new VRRemoteException ( e ); }
}

We call some find method with some collection of arguments, represented by the Object[], which could also be absent for an no-argument finder.

With the pattern identified let's "script" it using the dynamic method calling and the fact that the related class names all follow a convention.

Here's the code that will call any finder using the pattern above:

public Object find (String finder, Object[] args) {
	Object result = sendMessage (finder, getLocalHome(), args);
	if (result instanceof Collection) {
		try {
			Collection originalResultList = (Collection) result;

			// If the result is empty there is nothing to convert. Return the empty collection.
			if (originalResultList.size() == 0) {
				return result;
			}

			Collection resultList = new ArrayList ( originalResultList.size () );
			for (Iterator itr = originalResultList.iterator (); itr.hasNext (); ) {
				Object ejb = itr.next ();
				resultList.add (createPojo (ejb) );
			}
			result = resultList;
		} catch (Exception e) {
			throw new VRUtilityException ("ERROR: Post-processing a collection into POJO's for type = '" + getType() + "'.", e);
		}	
	} else {
		// Build a POJO from the EJB entity returned by the finder.
		return createPojo (result);
	}
	
	return result;
}

Most of the code in the method is involved with transforming Collection results into POJO's.

To access the findById method I'd do:

return (TYPE) find ("findById", new Object[] { id } )

Getting the LocalHome interface is done by convention:

/** Get the local home appropriate to this mixin. */
protected Object getLocalHome () {
	// Determine utility class name.
	Class utilClass = findClass (getType() + "Util");
	if (utilClass == null) {
		throw new VRUtilityException ("ERROR: Could not look up utility class for type = '" + getType () + "' by convention.");
	}
	try {
	       return utilClass.getMethod ("getLocalHome", null).invoke (null, null);
	} catch (Exception e) {
		throw new VRUtilityException ("ERROR: Could isntantiate local home for class of type = '" + getType () + "' by convention using Method object.");
	}
}

Because I know my Util class is #TYPE#Util I can rely on that by convention to get my utility class and instantiate a LocalHome to be used. (In my case the findClass() method looks for the #TYPE#Util class in one of three packages by convention. I could have search the classpath, but that seemed like overkill under the circumstances, when I know it's in one of those three packages.)

Using the same recognition of patterns and convention allowed the replacement of boilerplate code in our persist method to.

Before:

public void persist ( Endowment endowment ) {
	try {
		// get the local home
		EndowmentLocalHome endowmentLH = EndowmentUtil.getLocalHome ();
		// create the entity
		EndowmentLocal endowmentL = endowmentLH.create ();
		// ensure that the foreign keys are set
		setForeignKeys ( endowment );
		// populate the entity
		endowmentL.setEndowmentValue ( endowment );
		// update the ID
		endowment.setId( endowmentL.getId() );
	} catch ( Exception e ) { throw new VRRemoteException ( e ); }
}

After:

public void persist ( Endowment endowment ) {
	mixin.persist (endowment);
}

The reflection code that does it:

public void persist (Object bean) {

	// Create an entity EJB bean using the localHome.
	Object ejb = sendMessage ("create", getLocalHome (), null);
		
	// Populate foreign ID's from associated POJO's.
	setForeignKeys (bean);
		
	// Populate the entity.
	setValueOnEjb (bean, ejb);
		
	// Get the id from the ejb.
	String id = (String) sendMessage ("getId", ejb, null);
		
	// Set the id on the bean (POJO).
	sendMessage ("setId", bean, new Object[] { id });
}

The nice thing is I wrote the reflection version of the persist once and I can reuse it with one line of code. Bye bye boiler plate.

Conclusion

If you find yourself writing repetitive code, such as in my case when wrapping some API you want to abstract out, find the patterns and factor out that repetitive boilerplate code using reflection. You don't need to waste your life writing repetitive code.

Groovy : Currying closures

2008-03-02T13:32:00.001-08:00

This is just a quick Groovy feature that I think is cool.
For my reporting page, I want to produce a whole bunch of stats based on the duration of my trades. What is my average net, %age, and R gains for my winners and losers? Am I making more money per day with my winners than with my losers (ie: am I cutting the crap short and holding my winners)? Each calculation is essentially the same, just with some minor permutations. The basic structure will be:

for each trade in a list
 num days += trade.num days
 currVal += trade.currVal
return currVal / num days

The problem is that I need to do this calculation for all of my winners, losers and breakeven trades, and for each list, I need to do several different calculations. This is hardly intractable, it just makes a messy loop with lots of temp variables.

Groovy lets you do a couple cool things. First, you can define a closure which is sort of like an anonymous inner class in Java, except without the class. It's really just a method pointer. So we can start by defining a closure to calculate the average dollar value:

def avgDollar = {ts -> ts?.sum{it.net()} / (ts ? ts.sum{it.duration()} : 1) }

The notation ts?.sum is groovy's way of checking for nulls so instead of writing:

double val = 0;
if( ts != null ) {
   val = ts.sum();
}

you just say:

def val = ts?.sum()

Cool, no? Makes it easy to do the "right" thing and check for nulls without messing up your code. Anyway...

So now that we have our closure, we can say:

def avgDlrWins = avgDollar(winners)
def avgDlrBE = avgDollar(breakEvens)
def avgDlrLoss = avgDollar(losers)

That's a step in the right direction, but now we have to do the same mess when we try to average R's and %ages. So now we step up our game and do some meta-programming, defining a closure to pass to our closure!

def holdAvg = {clos, ts -> ts?.sum{clos.call(it)} / (ts ? ts?.sum{it.duration()} : 1) }

This closure takes two arguments, closure and a list of trades and sums the result of calling the closure and dividing that by the sum of the duration. That lets us create our sub closures as:

def avgDollar = holdAvg.curry({it.net()})
def avgR = holdAvg.curry({it.r()})
def avgPerc = holdAvg.curry({it.percent()})

The method "curry" binds the first argument of the holdAvg closure to the argument we pass in (in this case another closure). That means that the avgDollar() closure we just define is fully equivalent to the first one, only now we can quickly rattle off the avgR and avgPercent closure. Now that's code re-use!

If you haven't used closures before, this is probably a bit weird-looking and when I first read about curried closures, I couldn't see how they'd be used, but it's surprising how often they pop up when you know that the feature exists.

Good coding!

A new approach to the equals() method!

2007-11-12T13:56:00.000-08:00

Custom equals() methods are handy but involve writing a lot of ugly boilerplate code — and there are booby-traps for the unwary. In this post, I present a way of over-riding equals() and hashCode() methods — based on annotations — which makes them a doddle to implement and maintain. The resulting code is available for download in a shrink-wrapped jar.

To recap, a == b tests whether a and b are the same object. a.equals(b) tests whether they are equivalent objects. equals() is a very useful method, and you will no doubt have found yourself over-riding the default version in several of your classes.

Over-riding equals() is not quite as straightforward as it seems. You must also override hashcode() in an equivalent manner. Otherwise HashSet, HashMap and HashTable will exhibit strange bugs. I’ve made this mistake and it’s confusing as hell to debug. Josh Bloch’s Effective Java provides more examples of how equals can go wrong.

Also equals() and hashCode() methods contain a lot of boilerplate. Here’s an example of equals() for a class — and this is for a simple class with only 2 fields:


public boolean equals(Object obj) {
       if (this == obj)
           return true;
       if (obj == null)
           return false;
       if (getClass() != obj.getClass())
           return false;
       final ToyStoryState other = (ToyStoryState) obj;
       if (leftBank == null) {
           if (other.leftBank != null)
               return false;
       } else if (!leftBank.equals(other.leftBank))
           return false;
       if (torch == null) {
           if (other.torch != null)
               return false;
       } else if (!torch.equals(other.torch))
           return false;
       return true;
}

Yuck!
Annotations to the rescue!

There is a nice solution to this issue using annotations. We’ll start with an example, then look behind the scenes at how it works.

Example


class MyObject {

   @Equals
   public String name;

   private int id;

   @Equals
   public int getId() {
       return id;
   }

   public boolean equals(Object obj) {
       return Equality.equalsByAnnotation(MyObject.class, this, obj);
   }

   public int hashCode() {
       return Equality.hashCodeByAnnotation(MyObject.class, this);
   }

}

With the example above, two MyObjects are considered equal if they have the same name and id — as returned by getId(). Equals is our custom annotation, and Equality is a support class with static methods…

Making it work

We need to know which properties are important for equality. Properties can be fields or zero-argument methods, such as getters. This can be specified in a natural way by annotating fields and methods. First we define an annotation for properties that should be tested: @Equals indicates a property that should be compared using equals(). Defining an annotation is similar to defining an interface, except you use the keyword @interface, and you’ll usually want to add some meta-annotations.


@Retention(RetentionPolicy.RUNTIME) // Meta-annotation for "Don't throw this away during compilation"
@Target( { ElementType.FIELD, ElementType.METHOD }) // Meta-annotation for "Only allowed on fields and methods"
public @interface Equals {

}

Now we can annotate properties like in the example — how do we test them? We need to make use of the reflection api. Given a Class object, we can get it’s Field and Method objects via Class.getDeclaredFields/Methods(). Given those, we test for the presence of annotations using Field/Method.isAnnotationPresent(). We use a little known Java feature to get access to non-public fields — see this post for details. I put the code for all this is in a class Equality under the static methods equalsByAnnotation() and hashCodeByAnnotation() — you can download it below.

Checking the superclass

Note that the equalsByAnnotation() method does not look at properties belonging to ancestor classes. Similarly, hashcodeByAnnotation() does not incorporate properties belonging to ancestor classes. If this is necessary, the user must call super.equals() and super.hashcode(). E.g. like this:


if ( ! super.equals(obj)) return false;
return equalsByAnnotation(MyObject.class, this, obj);

and


return 17*super.hashcode() + hashcodeByAnnotation(this);

This is a deliberate design decision. If the parent class has over-ridden equals(), then it’s method (which may or may not use annotations) must be checked. I’ve left this as the user’s responsibility - partly so they keep control, partly because the code to check for an ancestor equals method would have been ugly. If you think it should be handled automatically, feel free to send me your code suggestions…

Advantages

Shorter code, cleaner code, God kills less kittens, etc. Having @Equals attached to fields and methods makes it clear what is and isn’t being tested. This helps in maintaining correct behaviour when the class is edited. And it isn’t restrictive — you can still write your own custom code if you need to.

The Disadvantage: Speed

So the code is a lot nicer — but naturally you lose a bit of speed. I did some time trials, and the annotations based method came out as 3x slower. That’s fine during development and if equals() / hashCode() are not bottlenecks. Note that equals() and hashCode() can be bottlenecks — e.g. when making intensive use of Maps. So you may not want to use this in some production systems.

Creating PDF Documents Dynamically in J2EE, Java Applications

2007-11-09T13:23:00.001-08:00

Background:
In today's enterprise applications their is a big requirement for dynamic generation of PDF documents. These applications range from telecom companies generating phone bills, airlines producing e-tickets, banks generating customer statements for e-mail delivery to readers, book sellers selling books in pdf format.

What is PDF:
The Portable Document Format (PDF) is the file format created by Adobe Systems in 1993 for document exchange. PDF is used for representing two-dimensional documents in a device-independent and display resolution-independent fixed-layout document format. Each PDF file encapsulates a complete description of a 2-D document (and, with Acrobat 3-D, embedded 3-D documents) that includes the text, fonts, images, and 2-D vector graphics that compose the document.

Why PDF:
PDF is an open standard, unlike Microsoft Word, supported by all operating systems, ie; as long as you have an adobe reader you can read a pdf file on any system like Linux, Mac, Solaris, Windows. On virus front, it’s very hard that a PDF file will have some virus. It is is now being prepared for submission as an ISO standard.

Dynamic PDF Generation in Enterprise Application Development :
As mentioned above, in digital age everything is digitized so that end user can access it from anywhere, anytime. As a result new enterprise applications are generating lot of data in pdf formant which can be used by end user.
In Enterprise (Java or J2EE, JEE) application development generating pdf documents on the fly (dynamically) has become a trivial thing, courtesy of lot of third party tools, APIs available. The list of these tools/API's is endless. In this article, we will use the iText Java library to generate PDF documents by merging GIF files. I'll go through an example to show how this is done.

iText :
iText is an open-source Java library that provides API to generate PDF files on the fly. It also supports the generation of HTML, RTF, and XML documents, in addition to generating PDFs. It's available for free under a multiple license: MPL and LGPL.

iText API :

The com.lowagie.text.Document is the main class for PDF document generation. This is the first class to be instantiated. Once the document is created, we would require a writer to write into it. The com.lowagie.text.pdf.PdfWriter is a PDF writer. Other classes which are often used:

com.lowagie.text.Paragraph - represents an indented paragraph.
com.lowagie.text.Chapter - represents a chapter in the PDF document. It is created using a Paragraph as title and an int as chapter number.
com.lowagie.text.Font - contains all specifications of a font, such as family of font, size, style, and color. Various fonts are declared as static constants in this class.
com.lowagie.text.List - represents a list, which, in turn, contains a number of ListItems.
com.lowagie.text.Table - represents a table that contains cells, ordered in a matrix.

Example of converting multiple GIF files into PDF :

Pre-requisites :
Download iText and include itext-version.jar into your application or yr classpath.

Code Snippet :
The following code snippet demonstrates how to convert an array (collection) of gif files into a single pdf,


FileOutputStream fos = null;

try {

 fos = new FileOutputStream (new File(pDestinationFolder + File.separator + pTargetFileNamePrefix + ".pdf"));

 /* Create a document which is the container for all the elements of a PDF document.*/
 Document doc = new Document();

 /* Line -1 */
 PdfWriter writer = PdfWriter.getInstance(doc, fos);
 
 doc.open();
 
 for (File aFile : gifFiles)  {
 
  Image image = Image.getInstance(aFile.getAbsolutePath());
  
  /* Line -2 */
  image.scaleToFit(doc.getPageSize().getWidth(), doc.getPageSize().getHeight());
  
  /* Line -3 */
  image.setAlignment(Image.ALIGN_CENTER);
  doc.add(image);
  doc.newPage();
 }
 
 doc.close();
}
catch (Exception ex) {
 ex.printStackTrace();
}
finally {
 
  if (fos != null)  {
  try  {
   fos.close();
  }
  catch (Exception ex)  {
   ex.printStackTrace();
  }
 }
}

Code Demystified :

Line - 1 is important to create an instance of PdfWriter that associates a document object with the output stream. For our code snippet, we choose com.lowagie.text.pdf.PdfWriter. Other writers are HtmlWriter, RtfWriter, XmlWriter, and several others for obvious reasons.
Line - 2 is very useful methods that will scale the current image to fit the width and height specified. Gif images can vary in sizes and this allows the method to scale down to the default size of the PDF page.
Line-3 is to align the image so that it is located at the center of the page.

Other opensource libraries for generating pdf documents are :

FOP
Gnujpdf
JFreeReport
JPedal
jPod
PDF Box
PDFjet
PJX

Serialization in Java/J2EE - Demystified

2007-11-08T12:40:00.000-08:00

Serialization:

Serialization is the process of persisting the state of an object.
In Java serializing an object involves encoding its state in a structured way within a byte array. Once an object is serialized, the byte array can be manipulated in various ways; it can be written to a file, sent over a network or RMI, or persisted within a database as a BLOB.

The serialization process encodes enough information about the object type within the byte stream, allowing the original object to be easily recreated upon deserialization, at a later point in time.
Serialization and Deserialization is same as marshaling and unmarshaling in C/C++.

Where to keep serialized object:

Serialization is a highly versatile mechanism it should be addressed by storing the state in relational or object databases. It does not have transaction management and concurrency control. Nor does it provide any typical database features like indexed access, caching and a query language.

Serializing static variables:

Variables declared as static members are not considered part of the state of an object because they are shared by all instances of that class. Classes which need to preserve the value of static members during serialization should save and restore these values explicitly using private void readObject(ObjectInputStream) and private void writeObject(ObjectOutputStream).

Advantages and Disadvantages:

The advantages of serialization are:

It is easy to use and can be customized.
The serialized stream can be encrypted, authenticated and compressed, supporting the needs of secure Java computing.
Serialized classes can support coherent versioning and are flexible enough to allow gradual evolution of your application's object schema.
Serialization can also be used as a mechanism for exchanging objects between Java and C++ libraries, using third party vendor libraries within C++.
Many vital technologies that rely upon serialization, including RMI, JavaBeans and EJB.

Disadvantages:

It should ideally not be used with large-sized objects, as it offers significant overhead. Large objects also significantly increase the memory requirements of your application since the object input/output streams cache live references to all objects written to or read from the stream until the stream is closed or reset. Consequently, the garbage collection of these objects can be inordinately delayed.
Serializable interface does not offer fine-grained control over object access - although you can somewhat circumvent this issue by implementing the complex Externalizable interface, instead.
Since serialization does not offer any transaction control mechanisms, it is not suitable for use within applications needing concurrent access without making use of additional APIs.

Criteria for a class to be Serializable:

Have access to a no-argument constructor in its first non-serializable superclass
Identify non-serializable data members using the transient keyword or explicitly mark data members as serializable using the serialPersistentFields member.

My subclass implements Serializable but my superclass doesn't. Both subclass and superclass contain instance variables that need to be saved as part of the state of the subclass. Will serialization save the superclass fields for me?

When you serialize an object, the serialization mechanism works by chaining up the inheritance hierarchy, saving the sate of each Serializable superclass in turn. When serialization reaches the first non-serializable superclass, the serialization stops.

When deserializing, the state of this first non-serializable superclass is restored not from the stream, but by invoking that class' no-argument constructor. If the no-argument constructor is not adequate for your purposes, you must customize the serialization of your subclass with writeObject() and readObject() in order to write out and restore any information from the non-serializable superclass that you find necessary.

Externalizable instead of Serializable:

By implementing Externalizable yourself you can win performance at the cost of flexibility and extra code to maintain. If you implement Externalizable yourself you stream the data directly without the need for reflection which is used in the case of Serializable

Read and write serialized objects to and from a database:

If your RDBMS supports them, you can store serialized objects as BLOBs.
These are JDBC 2.0 features, but take a look at java.sql.Blob, ResultSet and PreparedStatement for more information.

Collections like Vector or a Hashtable:

Collections like Vector and Hashtable both implements Serializable and have been designed for serialization.
One thing to keep in mind is to watch out for is, that in order to serialize a collection like Vector or Hashtable, you must also be able to serialize all of the objects contained in these collections. Otherwise, the collection would not be able to be completely restored. Your program will throw a NotSerializableException unless all objects stored in the Vector or Hashtable are also serializable.

Other way to save the state of an object of a class which does not implement Serializable or Extenalizable

Write the value of each and every instance variable into the persistent storage. If there are 50 variables, you will have to store each of them individually. If some of the variables are object references, you will have to follow each reference and save the state of that object as well. You can do that, but it would be a proprietary solution and each class that wanted to read your object would also have to know all about your proprietary format.

Role of serialization in RMI:

RMI uses serialization as its basic and only mechanism for sending objects across a network.
If an object implements java.rmi.Remote, then the object's stub is serialized and sent to the client. If the object implements java.io.Serializable, then the object itself is serialized and sent.

Role of serialization in EJB:

A big part of EJB is that it is a framework for underlying RMI: remote method invocation. You're invoking methods remotely from one JVM space 'A' on objects which are in JVM space 'B' -- possibly running on another machine on the network.
To make this happen, all arguments of each method call must have their current state plucked out of JVM 'A' memory, flattened into a byte stream which can be sent over a network connection, and then deserialized for reincarnation on the other end in JVM 'B' where the actual method call takes place.
If the method has a return value, it is serialized up for streaming back to JVM 'A.' Thus the requirement that all EJB methods arguments and return values must be serializable. The easiest way to do this is to make sure all your classes implement java.io.Serializable.

J2EE Tutorial on JAX WS Style Webservices using JBoss

2007-10-09T13:14:00.000-07:00

Continuing from part 1, this part will cover the following porting steps in

1.3 Porting Steps

1.3.1 Naming conventions
1.3.2 Generate stubs
1.3.3 Ant target to generate stubs
1.3.4 Test Webservices client
1.3.5 Configure Logging SOAP packet (incoming and outgoing)
1.3.6 Instructions for setting up SOAP packet logging on client side
1.3.7 Test client code snippet

1.3.1 Porting Steps

To port JBoss Webservices stack from JBoss 4.0.4 to 4.2 >= without breaking interoperability from JAX-RPC style webservices to JAX-WS style web services few steps are required.

WSDL (which act as a contract) generated previously has to be modified to work with JAX-WS compliant JbossWS.
Some naming conventions has to be followed while generating new WSDL so that stubs are generated with ease.
Generate Stubs
Logging SOAP Packet Logging

1.3.1.1 Diffrences between WSDL's

Here is an old generated WSDL using JAX-RPC Stack on JBoss

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions name="matt_HelloWorld3" targetNamespace="http://www.vishal.com.au/matt.HelloWorld3"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.vishal.com.au/matt.HelloWorld3">

<wsdl:types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://localhost/matt/HelloWorld3/HelloWorld" xmlns:tns="http://localhost/matt/HelloWorld3/HelloWorld" xmlns:edm="http://www.vishal.com.au/matt.HelloWorld3">

<xsd:import namespace="http://www.vishal.com.au/matt.HelloWorld3"/>

<xsd:complexType name="HelloWorldRequest">
<xsd:sequence>

<xsd:element name="id" nillable="true" type="xsd:string"/>

</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="HelloWorldRespons">
<xsd:sequence>
<xsd:element name="result" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"  targetNamespace="http://www.vishal.com.au/matt.HelloWorld3"
xmlns:edm="http://www.vishal.com.au/matt.HelloWorld3"
xmlns:tns="http://localhost/matt/HelloWorld3/HelloWorld">
<xsd:import namespace="http://localhost/matt/HelloWorld3/HelloWorld"/>

<xsd:element name="HelloWorld" type="tns:HelloWorldRequest"/>

<xsd:element name="HelloWorldRespons" type="tns:HelloWorldRespons"/>

</xsd:schema>

</wsdl:types>
<wsdl:message name="HelloWorld">
<wsdl:part name="HelloWorld" element="tns:HelloWorld"/>
</wsdl:message>
<wsdl:message name="HelloWorldOutput">
<wsdl:part name="HelloWorldRespons" element="tns:HelloWorldRespons"/>
</wsdl:message>
<wsdl:portType name="matt_HelloWorld3PortType">
<wsdl:operation name="HelloWorld">
<wsdl:input message="tns:HelloWorld"/>
<wsdl:output message="tns:HelloWorldOutput"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="matt_HelloWorld3Binding" type="tns:matt_HelloWorld3PortType">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="HelloWorld">
<soap:operation soapAction=""/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="matt_HelloWorld3Service">
<wsdl:port name="matt_HelloWorld3Port0" binding="tns:matt_HelloWorld3Binding">
<soap:address location="http://spthd01:5565/soap/DocLiteral"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Modified WSDL for JAX-WS stack in JBoss

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions name="matt_HelloWorld3"
targetNamespace="http://www.vishal.com.au/matt.HelloWorld3"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.vishal.com.au/matt.HelloWorld3">


<wsdl:types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.vishal.com.au/matt.HelloWorld3"
xmlns:edm="http://www.vishal.com.au/matt.HelloWorld3">


<xsd:element name="HelloWorld" 
type="edm:HelloWorldRequest"/>

<xsd:element name="HelloWorldRespons" type="edm:HelloWorldRespons"/>
<xsd:complexType name="HelloWorldRequest">
<xsd:sequence>
<xsd:element name="id" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="HelloWorldRespons">
<xsd:sequence>
<xsd:element name="result" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

</wsdl:types>

<wsdl:message name="HelloWorld">
<wsdl:part name="HelloWorld" element="tns:HelloWorld"/>
</wsdl:message>
<wsdl:message name="HelloWorldOutput">
<wsdl:part name="HelloWorldRespons" element="tns:HelloWorldRespons"/>
</wsdl:message>
<wsdl:portType name="matt_HelloWorld3PortType">
<wsdl:operation name="HelloWorld">
<wsdl:input message="tns:HelloWorld"/>
<wsdl:output message="tns:HelloWorldOutput"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="matt_HelloWorld3Binding" type="tns:matt_HelloWorld3PortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="HelloWorld">
<soap:operation soapAction=""/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="matt_HelloWorld3Service">
<wsdl:port name="matt_HelloWorld3Port0" binding="tns:matt_HelloWorld3Binding">
<soap:address location="http://spthd01:5565/soap/DocLiteral"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Difference between original WSDL and modified WSDL

No import statement required here
HelloWorld is not a complex type but just an element, if it is complex type it adds another layer in SOAP Packet
Similarly HelloWorldRespons is not a complex type but just an element

1.3.1 Naming conventions

For naming conventions lets look at code snippet from original wsdl

JAX-WS specification is pedantic about method name and
input argument name.
It says method name has to same as arguement name, otherwise
it will not work_. Here elemnet="tns:HelloWorld" is the
input argument and name="HelloWorld" is just a local name.

<wsdl:message name="HelloWorld">
<wsdl:part name="HelloWorld" element="tns:HelloWorld" />
</wsdl:message>

JAX-WS specification also _recommends_ to name return type,
suffix with word _Response_.

In this case its not used, it is using word _Respons_ with missing _e_.
Here elemnet="tns:HelloWorldRespons" is the output arguement
and name="HelloWorldRepons" is just a local name.

<wsdl:message name="HelloWorldOutput"><wsdl:part 
name="HelloWorldRespons" element="tns:HelloWorldRespons" />
</wsdl:message>

Here method/function/behavior prototype is declared.
Method name is _HelloWorld_ (operation name="HelloWorld")
same as input arguement (element="tns:HelloWorld" defined
under message name="HelloWorld".
This has to be same, otherwise it will not work/generate
right stubs.

<wsdl:portType name="matt_HelloWorld3PortType">
<wsdl:operation name="HelloWorld">
<wsdl:input message="tns:HelloWorld" />
<wsdl:output message="tns:HelloWorldOutput" />
</wsdl:operation></wsdl:portType>
<wsdl:binding name="matt_HelloWorld3Binding" 
type="tns:matt_HelloWorld3PortType">

Web services Style is document/literal and Wrapped. Wrapped
word is not mentioned, but it is the type of
arguements/paratmeters used in method/operation which
identfies it whether it is a Wrapped or non Wrappped service.
If an operation parameter uses element in declartion then
it is wrapped. In our case it is this 

<wsdl:part name="HelloWorld" element="tns:HelloWorld" />
which makes it warpped.

For non warpped it will be

<wsdl:part name="HelloWorld" type="xsd:string" />
<soap:binding style="document" 
transport="http://schemas.xmlsoap.org/soap/http" />
Document type 

<wsdl:operation name="HelloWorld">
<soap:operation soapAction="" /><wsdl:input>
<soap:body use="literal" />
Literal Type

</wsdl:input><wsdl:output>
<soap:body use="literal" /></wsdl:output>
</wsdl:operation></wsdl:binding>

1.3.2 Generate Stubs

To generate stubs new tools sets are usd in JBoss 4.2 >= series.
Previuously it used to use wstools bundled with JBoss 4.0.4, now it uses
wsconsume and wsprovide.

Wsconsume is used for top down approach - i:e; to generate stubs from WSDL

Wsprovide is used for bottom up approach
For both of them their are ant targets as well.

For this exercise I have used command line tools.

Command to generate stubs from WSDL.


vsm@jm000606:client11$ ~/javadev/jboss/bin/wsconsume.sh  -k -p au.com.hello.client11.test.orig HelloWorldOrig.wsdl
JBossWS-Native stack deployed
parsing WSDL...

generating code...
au.com.hello.client11.test.orig.HelloWorldRequest.java
au.com.hello.client11.test.orig.HelloWorldRespons.java
au.com.hello.client11.test.orig.MattHelloWorld3PortType.java
au.com.hello.client11.test.orig.MattHelloWorld3Service.java
au.com.hello.client11.test.orig.ObjectFactory.java
au.com.hello\client11.test.orig.package-info.java
vsm@jm000606:client11$

I'm using unix based tools but you can use wsconsume.bat on windows.~~

1.3.3 Ant target to generate stubs

<!-- Ant task for wsconsume -->

<!-- Ant task for wsprovide -->


<taskdef name="WSProvideTask"
classname="org.jboss.wsf.spi.tools.ant.WSProvideTask">
<classpath refid="web.services.classpath"/>
</taskdef>

<WSProvideTask
     fork="false"
     keep="true"
     destdir="out"
     resourcedestdir="out-resource"
     sourcedestdir="out-source"
     genwsdl="true"
     verbose="true">
   
</WSProvideTask>

</target>

1.3.3.1 More on wsconsume options:
If -keep option is set, the generated java files will be removed. -keep option is automatically set by WSConsume tool if you'll specify sourcedestdir attribute in your apache ant task.

Thus if you will specify sourcedestdir, the generated java files will not be deleted after the compilation phase.

So sourcedestdir points to the directory, where WsimportTool will generate java files
While destdirpoints to a directory where these java files will be compiled to class files.

1.3.4 Test Webservices Client

Now only remaining bit is to write a Test Client and invoke the service.
Code snippet from test client.

public class TestWSClient {

static Logger log = Logger.getLogger(TestWSClient.class);

public static void main(String[] args)
{
// TODO Auto-generated method stub

PropertyConfigurator.configure(
"D:/javadev/eclipse_workspace/TestWs/src/au/com/hello/client2/log4j.properties");

Logger log = Logger.getLogger(TestWSClient.class);
log.info("Got My logger going -1 ");

MattHelloWorld3Service service = new MattHelloWorld3Service();
MattHelloWorld3PortType port =  service.getPort(MattHelloWorld3PortType.class) ;

BindingProvider bp = (BindingProvider) port;
bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "test");
bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "test");

log.info ("Got My logger going -2");

HelloWorldReq memreq = new HelloWorldReq();

String response =   port.helloWorld("Hi Vishal");
System.out.println (" Returned messages is " + response);
}
}

1.3.5 Logging SOAP Packet

First configure your JBoss Server side.
Go to jboss-log4j.xml under conf directory.
Uncomment this section

<!-- Enable JBossWS message tracing
<category name="jbossws.SOAPMessage">
<priority value="TRACE"/>
</category>
-->

1.3.6 Instructions for setting up SOAP packet logging on client side
Create a log4j.properties file with these options


# Set root logger level to ALL and its only appender to A1.
log4j.rootLogger=ALL, A1

# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender
# Other appenders can be used here and can bee added to root

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

Now inside your test client add this line which configures this logging.


PropertyConfigurator.configure("D:/javadev/eclipse_workspace/TestWs/src/au/com/hello/client2/log4j.properties");

Now when you will run your server it will log outgoing and incoming soap packets

Outgoing SOAP packet is

<env:Envelope 
xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
<env:Header/>
<env:Body>
<ns1:HelloWorld xmlns:ns1='http://www.vishal.com.au/matt.HelloWorld3'>
<id>Hi Vishal</id>
</ns1:HelloWorld>
</env:Body>
</env:Envelope>

Incoming SOAP packet is

<edm:HelloWorldRespons
xmlns:edm="http://www.vishal.com.au/matt.HelloWorld3">
<result>Hello Hi Vishal</result>
</edm:HelloWorldRespons></SOAP-ENV:Body>
</SOAP-ENV:Envelope>

1.3.7 Test client code snippet



public static void main(String[] args) {

PropertyConfigurator.configure("D:/javadev/eclipse_workspace/TestWs/src/au/com/hello/client2/log4j.properties");

log.info("Got My logger going -1 ");

MattHelloWorld2Service service = new MattHelloWorld2Service();
MattHelloWorld2PortType port =  service.getPort(MattHelloWorld2PortType.class) ;

BindingProvider bp = (BindingProvider) port;
bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "test");
bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "test");

log.info ("Got My logger going -2");

HelloWorld2 memReq = new HelloWorld2();
memReq.setId("Hellow Mathew");

HelloWorld2Respons resp = port.getMessage(memReq);

System.out.println (" Returned messages is " );

}



Opensource Cache/Caching Solutions in Java
2007-10-09T13:03:00.000-07:00
Background:
In computer science, a cache is a collection of data duplicating original values stored elsewhere or computed earlier, where the original data is expensive to fetch (due to slow access time) or to compute, relative to the cost of reading the cache. In other words, a cache is a temporary storage area where frequently accessed data can be stored for rapid access. Once the data is stored in the cache, future use can be made by accessing the cached copy rather than re-fetching or recomputing the original data, so that the average access time is lower. Cache, therefore, helps expedites data access otherwise the CPU would need to fetch from main memory. Cache have proven to be extremely effective in many areas of computing because access patterns in typical computer applications have locality of reference. 

Purpose :
The main purpose of the caching service is to improve server performance by managing static and non static data members. The performance gain is from reducing the number of trips to the database or other external sources of information, avoiding the cost of repeatedly recreating data (objects in java), sharing data between threads in a process and, when possible between processes, and efficient use of process resources.

Advantages: 
In a multi-tiered (n-tier) application, data access is an expensive operation, compared to any other task. By keeping the frequently accessed data around and not releasing it after the first use, we can avoid the cost and time required for the reacquisition and release of the data. This results in greatly improved performance, since we won't be hitting the database every time we need the data.
Scalability is another reason of using. Since cached data is accessed across multiple tiers, sessions, components, caching can become a big part of a scalable application design.

Disadvantages:
Synchronization complexity: Depending on the kind of data, complexity increases, because consistency between the state of the cached data and the original data in the data source needs to be ensured. Otherwise, the cached data can get out of sync with the actual data, which will lead to data inaccuracies.
Durability: Changes to the cached data can be lost when the server crashes. This problem can be avoided if a synchronized cache is used. 
Memory size: JVM memory size can get unacceptably huge if there is lot of unused data in the cache and the data is not released from memory at regular intervals.

Opensource Caching solutions in Java:
There are lots of caching solution in Java, free and non free. This is a list of opensource caching solutions available in Java/J2EE/JEE domain for software development or developing enterprise applications.

Bamboo DHT - is a distributed hash table, or DHT, is a building block for peer-to-peer applications. At the most basic level, it allows a group of distributed hosts to collectively manage a mapping from keys to data values, without any fixed hierarchy, and with very little human assistance. This building block can then be used to ease the implementation of a diverse variety of peer-to-peer applications such as file sharing services, DNS replacements, web caches, etc.

cache4j - is a cache for Java objects with a simple API and fast implementation. It features in-memory caching, a design for a multi-threaded environment, both synchronized and blocking implementations, a choice of eviction algorithms (LFU, LRU, FIFO), and the choice of either hard or soft references for object storage.

FreePastry - is a modular, open source implementation of the Pastry p2p routing and location substrate. Pastry is a generic, scalable and efficient substrate for peer-to-peer applications. Pastry nodes form a decentralized, self-organizing and fault-tolerant overlay network within the Internet. Pastry provides efficient request routing, deterministic object location, and load balancing in an application-independent manner. Furthermore, Pastry provides mechanisms that support and facilitate application-specific object replication, caching, and fault recovery. The proponents of Pastry work for Microsoft, however they've made an excellent choice sticking with Java.


EHCache - is a pure Java, in-process cache. It started as a replacement for JCS. EHCache is faster than JCS. It has following features: Fast,Simple, pluggable cache for Hibernate, small foot print, minimal dependencies, fully documented and production tested.

Java Caching System (JCS) - is a distributed caching system written in java for server-side java applications. It is intended to speed up dynamic web applications by providing a means to manage cached data of various dynamic natures. Like any caching system, the JCS is most useful for high read, low put applications. Dynamic content and reporting systems can benefit most. However, any site that repeatedly constructs pages, drop downs, or common search results form a database that is updated at intervals (rather than across categories continuously) can improve performance and scalability by implementing caching. Latency times drop sharply and bottlenecks move away from the database in an effectively cached system.
It provides several important features, necessary for any Enterprise level caching system, features include Memory management, disk overflow, element grouping, quick nested categorical removal, data expiration, extensible framework, fully configurable run time parameters, remote synchronization, remote store recovery, non-blocking "zombie" pattern, optional lateral distribution of elements, remote server clustering and failover. These features provide a framework with no point of failure, allowing for full session failover including session data across up to 256 servers.

JBoss Cache - is a product designed to cache frequently accessed Java objects in order to dramatically improve the performance of e-business applications. By eliminating unnecessary database access, JBoss Cache decreases network traffic and increases the scalability of applications. But JBoss Cache is much more than a simple cache. JBoss Cache provides fully transactional features as well as a highly configurable set of options to deal with concurrent data access in the most efficient manner possible for your application. In addition, it is a clustered cache that replicates contents to other cache instances running on separate JVMs, servers or even entire networks, making JBoss Cache a highly efficient library used by application server developers to implement clustering features.
JBossCache consists of two modules
TreeCache - a replicated transactional tree-structured cache .
TreeCacheAop a subclass of TreeCache using AOP to dynamically replicate Plain Old Java Objects - POJO.

JCache - is an effort to make an Open Source version of JSR-107 JCache. Since the JSR-107 hasn't released any specs for years, This version still builds on the original functional specification. It is implemented by some  geeks at ThoughtWorks.

Jofti - is a simple to use, high-performance object indexing and searching solution for Objects in a Caching layer or storage structure that supports the Map interface. The framework supports EHCache, JBossCache and OSCache and provides for transparent addition, removal and updating of objects in its index as well as simple to use query capabilities for searching. Features include type aware searching, configurable object property indexing, indexing/searching by interfaces as well as support for Dynamic Proxies, primitive attributes, Collections and Arrays

OceanStore - is a global persistent data store designed to scale to billions of users. It provides a consistent, highly-available, and durable storage utility atop an infrastructure comprised of untrusted servers. OceanStore caches data promiscuously; any server may create a local replica of any data object. These local replicas provide faster access and robustness to network partitions. They also reduce network congestion by localizing access traffic. Pond, the OceanStore prototype, is currently available for download.

Open Terracotta - is Open Source Clustering for Java. Features: HTTP Session Replication, Distributed Cache, POJO Clustering, Application Coordination across cluster's JVM's (made using code injection, so you don't need to modify your code)

OSCache - is a caching solution that includes a JSP tag library and set of classes to perform fine grained dynamic caching of JSP content, servlet responses or arbitrary objects. It provides both in memory and persistent on disk caches, and can allow your site to have graceful error tolerance (eg if an error occurs like your db goes down, you can serve the cached content so people can still surf the site almost without knowing). Take a look at the great features of OSCache.

ShiftOne - is a Java Object Cache library that implements several strict object caching policies, as well as a light framework for configuring cache behavior. It's strict in the sense that each cache enforces two limits in a very strict and predictable way.

SwarmCache - is a simple but effective distributed cache. It uses IP multicast to efficiently communicate with any number of hosts on a LAN. It is specifically designed for use by clustered, database-driven web applications. Such applications typically have many more read operations than write operations, which allows SwarmCache to deliver the greatest performance gains. SwarmCache uses JavaGroups internally to manage the membership and communications of its distributed cache. Wrappers have been written that allow SwarmCache to be used with the Hibernate and JPOX persistence engines.

WhirlyCache -  is a fast, configurable in-memory object cache for Java. It can be used, for example, to speed up a website or an application by caching objects that would otherwise have to be created by querying a database or by another expensive procedure


Spring Framework - J2EE Development without EJB
2007-10-09T13:00:00.000-07:00
Background :
Spring is an open-source application framework, introduced and developed in 2004. The main ideas were suggested by an experienced J2EE architect, Rod Johnson. He had earlier, written a book titled J2EE Development without using EJB and had introduced the concept of Light-weight container. Primarily, his argument is that while EJB has its merits, it is not always necessary and suitable in all applications.
Just as Hibernate attacked CMP as primitive ORM technology, Spring attacked EJB as unduly complicated and not susceptible to unit-testing. Instead of EJB, Spring suggests that we make use of ordinary Java beans, with some slight modifications, to  get all the supposed advantages of EJB environment. Thus, Spring is posed as an alternative to EJB essentially. However, as a concession to the existing EJB investments, Spring is designed to operate with EJB if required.

Much of the philosophy and approach of Spring framework, however, predates, the latest EJB-3. As we know now that EJB-3 has absorbed a number of new ideas suggested by Spring and some more, to answer the criticisms. Their is a debate going on in the Java community about Spring and EJB-3. Spring is not a Persistence technology but a framework which allows plug in of other such technologies. But EJB-3 is primarily focused on Persistence Technology and  has now incorporated Hibernate, the best ORM to date.Talks are going on to incorporate another equally nice ORM Technology known as JDO, which provides for Object Database also. Moreover, EJB-3 's Attribute-Oriented Meta tags, help in vastly reducing the size of XML lines. Some have complained that Spring is still too dependent on XML files.
The main aim of Spring is to simplify the J2EE development and testing.


Spring Under The Hood :


Spring is a great framework for development of Enterprise applications. It is a light-weight framework for the development of enterprise-ready applications. Spring can be used to configure declarative transaction management, remote access to your logic using RMI or web services, mailing facilities and various options in persisting your data to a database. It can be used in modular fashion, allows to use in parts and leave the other components which is not required by the application.

Main Features of Spring Framework:

Transaction Management: Spring framework provides a generic abstraction layer for transaction management. This allowing the developer to add the pluggable transaction managers, and making it easy to demarcate transactions without dealing with low-level issues. Spring's transaction support is not tied to J2EE environments and it can be also used in container less environments.

JDBC Exception Handling: The JDBC abstraction layer of the Spring offers a meaningful exception hierarchy, which simplifies the error handling strategy

Integration with Hibernate, JDO, and iBATIS: Spring provides best Integration services with Hibernate, JDO and iBATIS.

AOP Framework: Spring is one of the best AOP framework

MVC Framework: Spring comes with MVC web application framework, built on core Spring functionality. This framework is highly configurable via strategy interfaces, and accommodates multiple view technologies like JSP, Velocity, Tiles, iText and POI.
But other frameworks can be easily used instead of Spring MVC Framework..

Spring Architecture :
Spring is well-organized architecture consisting of various modules. Modules in the Spring framework are:

1. Spring Aspect Oriented Programming (AOP)
AOP is used in Spring

a) To provide declarative enterprise services, especially as a replacement for EJB declarative services. The most important such service is declarative transaction management, which builds on Spring's transaction abstraction.

b) To allow users to implement custom aspects, complementing their use of OOP with AOP

2. Spring ORM
The ORM package is related to the database access. It provides integration layers for popular object-relational mapping APIs, including JDO, Hibernate and iBatis.

3. Spring Context
This package builds on the beans package to add support for message sources and for the Observer design pattern, and the ability for application objects to obtain resources using a consistent API.

4. Spring Web
The Web context module builds on top of the application context module, providing contexts for Web-based applications. As a result, the Spring framework supports integration with Jakarta Struts, JSF and webworks. The Web module also eases the tasks of handling multi part requests and binding request parameters to domain objects.

5. Spring DAO
The Spring's JDBC and DAO abstraction layer offers a meaningful exception hierarchy for managing the database connection, exception handling and error messages thrown by different database vendors. The exception hierarchy simplifies error handling and greatly reduces the amount of code that we need to write, such as opening and closing connections. This module also provide transaction management services for objects in a spring application.


6. Spring Web MVC
The MVC framework is a full-featured MVC implementation for building Web applications. The MVC framework is highly configurable via strategy interfaces and accommodates numerous view technologies including JSP, Velocity, Tiles and the generation of PDF and Excel Files.

7. Spring Core
The Core package is the most import component of the Spring Framework.
This component provides the Dependency Injection features. The BeanFactory provides a factory pattern which separates the dependencies like initialization, creation and access of the objects from your actual program logic.


What are Checked and UnChecked Exceptions
2007-09-09T13:24:00.000-07:00
A checked exception is some subclass of Exception (or Exception itself), excluding class RuntimeException and its subclasses.

Making an exception checked forces client programmers to deal with the possibility that the exception will be thrown. Ex, IOException thrown by java.io.FileInputStream's read() method·

Unchecked exceptions are RuntimeException and any of its subclasses. Class Error and its subclasses also are unchecked.

With an unchecked exception, however, the compiler doesn't force client programmers either to catch the exception or declare it in a throws clause. In fact, client programmers may not even know that the exception could be thrown. eg, StringIndexOutOfBoundsException thrown by String's charAt() method·

Checked exceptions must be caught at compile time. Runtime exceptions do not need to be as Errors often cannot be.


Java J2EE Interview Questions - 7
2007-06-09T13:05:00.000-07:00
Continuing our Java/J2EE/JEE  interview questions and answers series, today's questions are:

Q Describe the principles of OOPS.
A There are three main principals of oops which are called Polymorphism, Inheritance and Encapsulation. 

Q Explain the Encapsulation principle.
A Encapsulation is a process of binding or wrapping the data and the codes that operates on the data into a single entity. This keeps the data safe from outside interface and misuse. One way to think about encapsulation is as a protective wrapper that prevents code and data from being arbitrarily accessed by other code defined outside the wrapper. 

Q Explain the Inheritance principle.
A Inheritance is the process by which one object acquires the properties of another object. 

Q Explain the Polymorphism principle.
A The meaning of Polymorphism is something like one name many forms. Polymorphism enables one entity to be used as general category for different types of actions. The specific action is determined by the exact nature of the situation. The concept of polymorphism can be explained as "one interface, multiple methods". 

Q Explain the different forms of Polymorphism.
Answer: From a practical programming viewpoint, polymorphism exists in three distinct forms in Java:
Method overloading
Method overriding through inheritance
Method overriding through the Java interface

Q What are Access Specifiers available in Java?
A Access specifiers are keywords that determines the type of access to the member of a class. These are:
Public
Protected
Private
Defaults

Q Describe the wrapper classes in Java.
A Wrapper class is wrapper around a primitive data type. An instance of a wrapper class contains, or wraps, a primitive value of the corresponding type.

Q What's the difference between J2SDK 1.5 and J2SDK 5.0?
A There's no difference, Sun Microsystems just re-branded this version.

Q What would you use to compare two String variables - the operator == or the method equals()?
A I'd use the method equals() to compare the values of the Strings and the == to check if two variables point at the same instance of a String object.

Q Does it matter in what order catch statements for FileNotFoundException and IOExceptipon are written?
A Yes, it does. The FileNoFoundException is inherited from the IOException. Exception's subclasses have to be caught first.

Q Can an inner class declared inside of a method access local variables of this method?
A It's possible if these variables are final.

Q What can go wrong if you replace && with & in the following code:
String a=null; if (a!=null && a.length()>10) {...}
A A single ampersand here would lead to a NullPointerException.

Q What's the main difference between a Vector and an ArrayList
A Java Vector class is internally synchronized and ArrayList is not.

Q When should the method invokeLater()be used?
A This method is used to ensure that Swing components are updated through the event-dispatching thread.

Q How can a subclass call a method or a constructor defined in a superclass?
A Use the following syntax: super.myMethod(); To call a constructor of the superclass, just write super(); in the first line of the subclass's constructor.

Q You can create an abstract class that contains only abstract methods. On the other hand, you can create an interface that declares the same methods. So can you use abstract classes instead of interfaces?
A Sometimes. But your class may be a descendent of another class and in this case the interface is your only option.

Q What comes to mind when you hear about a young generation in Java?
A Garbage collection.

Q What comes to mind when someone mentions a shallow copy in Java?
A Object cloning.

Q If you're overriding the method equals() of an object, which other method you might also consider?
A hashCode()

Q You are planning to do an indexed search in a list of objects. Which of the two Java collections should you use:
ArrayList or LinkedList?
A ArrayList

Q How would you make a copy of an entire Java object with its state?
A Have this class implement Cloneable interface and call its method clone().

Q How can you minimize the need of garbage collection and make the memory use more effective?
A Use object pooling and weak object references.


Top 10 Popular Eclipse Plugin
2007-05-09T13:18:00.000-07:00
Eclipse is an open source platform with many vendors behind it. IBM started this initiative in response to take on SUN in IDE market and compete with their offerings in this space now known as Netbeans. Its name came from Lunar Eclipse (hint: think of what happens to Sun during Lunar Eclipse).

Since its inception Eclipse platform has come a long way. Its now one of the most popular platform for software development, esp in Java, J2EE development.  Strictly speaking it is not an IDE, it is a platform which allows you to plugin and play various components according to to your technical needs. Most of the plugins offered are opensource, but some companies have SAAS model for their plugin distributions, like MyEclipse.

To give you an insight on how eclipse IDE cum platform is used I have compiled a list of top ten popular plugin used.

Spring IDE
MyEclipse Enterprise Workbench
Mylyn   
Hibernate Synchronizer
Azzurri Clay 
FreeMarker IDE
J2EE Spider  
WindowBuilder Pro
Jigloo SWT/Swing 
Checkstyle Plug-in



How Can i find when a HttpSession is removed/timed-out
2007-05-09T13:16:00.000-07:00
1. Define a class named SessionTimeoutNotifier which implements javax.servlet.http.HttpSessionBindingListener.

2. Create a SessionTimeoutNotifier object and add it to the user session.

3. When the session is removed, SessionTimeoutNotifier.valueUnbound() will be called by the servlet engine.

4. You can implement valueUnbound() method to do whatever you want.


How to do a deep clone of an java object
2007-04-09T13:21:00.000-07:00
Clone() method by default create's a shallow copy. For deep clone/copy you have to either override clone() method or provide a separate method.

The simplest approach to deep cloning is to use serialization, where you serialize and deserialize the object and return the deserialized version. This will be a deep copy/clone, assuming everything in the object tree is serializable.
If everything is not serializable, you'll have to implement the deep cloning behavior on your own.

Assuming everything is serializable, the following code snippet should create a complete deep copy of the current class instance:

ByteArrayOutputStream byteArrOs = new ByteArrayOutputStream();
ObjectOutputStream objOs = new ObjectOutputStream(byteArrOs);
objOs.writeObject(this);

ByteArrayInputStream byteArrIs = new ByteArrayInputStream(byteArrOs.toByteArray());
ObjectInputStream objIs = new ObjectInputStream(byteArrIs);
Object deepCopy = objIs.readObject();


What is HTTP tunneling
2007-04-09T13:17:00.000-07:00
HTTP tunneling is a general technique whereby arbitrary data may be sent via an HTTP connection to and from CGI scripts or Java Servlets or other technology on a Web server. This is done by serializing the data to be transmitted into a stream of bytes, and sending an HTTP message with content type "application/octet-stream".  HTTP tunneling is also referred to as Firewall tunneling.

Common reasons for using HTTP-Tunnel
  * Need to bypass any firewall
  * Need secure internet browsing
  * Need to use favorite programs with out being monitored by work, school, ISP or government.
  * Extra security for online transactions
  * Encrypt Internet traffic.
  * Need to play online games
  * Visit sites that you were previously blocked from accessing
  * Prevent 3rd party monitoring or regulation of your Internet browsing and downloads
  * Use your favorite applications previously blocked
  * Hide your IP address


J2EE Tutorial on Webservices using JBoss
2007-01-09T13:10:00.000-08:00
This J2EE tutorial covers building and porting JAX-RPC style Webservices to JAX-WS.

Tools used for this tutorial exercise  are
JBossWs 2.0.1GA  (Jboss's JAX-WS implementation)
JBoss  4.2.1GA - (J2EE Application server)
Eclispe IDE 3.2 >=
Apache Ant

1.1 Background
1.1.1 JAX-RPC
1.1.2 JAX-WS
1.2 Differences
1.2.1.1 SOAP 1.2
1.2.1.3 WS-I's Basic Profiles
1.2.1.4 New Java features
1.2.1.5 The data mapping model
1.2.1.6 The interface mapping model

1.3 Porting Steps
1.3.1 Naming conventions
1.3.2 Generate Stubs
1.3.3 Ant target to generate stubs
1.3.4 Test Webservices Client
1.3.5 Logging SOAP Packet
1.3.6  Instructions for setting up SOAP packet logging on client side
1.3.7 Test client snippet

1.4 Integrate With EJB 3.0
1.4.1  Define a Remote Interface
1.4.2 Implement a Stateless Session Bean
1.4.3 Build Jar
1.4.4 Run an EJB Client


1.1 Background

1.1.1 JAX-RPC

JAX RPC style of webservices is built on JSR-101 specification.

JBoss 4.0.4 server comes with JBossWs 1.0 series which has support for JAX-RPC and non JAX-WS style,  i:e; JSR-101 (JAX-RPC) and JSR-109 (non JAX-WS) style webservices respectively, rather than JSR-181  (JAX-WS) compliant. Strictly speaking, JbossWS 1.0 is not a JAX-WS compliant as it is missing JSR-181 impelmentation.

It only supports SOAP 1.1.

1.1.2 JAX-WS

JAX-WS style of web services is built on JSR-224 specification.
It uses annotations (JSR-181) and new data binding stack JAXB. JbossWS 2.0 >= series which
is used in this porting exercise is JAX-WS compliant.

In addition to being JAX-WS compliant, for backward compatibilty it has support for JAX-RPC(JSR-101) and JSR-109 compliant services used in JBoss 4.0.4.

It supports SOAP 1.1 and SOAP 1.2.


1.2 Differences

Their are quiet a few notable differences between JAX-WS and JAX-RPC. Notable ones to keep in mind while porting are in italics.

1.2.1.1 SOAP 1.2

JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.

1.2.1.2 XML/HTTP

The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.

1.2.1.3 WS-I's Basic Profiles

JAX-RPC supports WS-I's Basic Profile (BP) version 1.0. JAX-WS supports BP 1.1. (WS-I is the Web services interoperability organization.)

1.2.1.4 New Java features

JAX-RPC maps to Java 1.4. JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
Java EE 5, the successor to J2EE 1.4, adds support for JAX-WS, but it also retains support for JAX-RPC, which could be confusing to today's Web services novices.


1.2.1.5 The data mapping model

JAX-RPC has its own data mapping model, which covers about 90 percent of all schema types. Those that it does not cover are mapped to javax.xml.soap.SOAPElement.

JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas.

1.2.1.6 The interface mapping model

JAX-WS's basic interface mapping model is not extensively different from JAX-RPC's; however:

JAX-WS's model makes use of new Java 5.0 features.
JAX-WS's model introduces asynchronous functionality.

1.2.1.7 The dynamic programming model

JAX-WS's dynamic client model is quite different from JAX-RPC's. Many of the changes acknowledge industry needs:
It introduces message-oriented functionality.
It introduces dynamic asynchronous functionality.
    JAX-WS also adds a dynamic server model, which JAX-RPC does not have.

1.2.1.7 MTOM (Message Transmission Optimization Mechanism)

JAX-WS, via JAXB, adds support for MTOM, the new attachment specification. Microsoft never bought into the SOAP with Attachments specification; but it appears that everyone supports MTOM, so attachment interoperability should become a reality.

1.2.1.8 The handler model

The handler model has changed quite a bit from JAX-RPC to JAX-WS.
JAX-RPC handlers rely on SAAJ 1.2. JAX-WS handlers rely on the new SAAJ 1.3 specification.

Part - 2 of tutorial is continued here