Importing Public Static Methods

Consider the way you get "assertNotNull" into a JUnit4 test. You do it like this:

import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertNull;
import static org.junit.Assert.assertTrue;

The public static methods of the class Assert are pulled into your lexigraphical context and now you can write code like this in your methods:

@Test
public void testStringyGoodness() throws Exception {
  String next = null;
  assertNull(next);
  next = "foo";
  assertNotNull(next);
  assertTrue(next.equals(foo));
}

And, all of this is relatively simple... but is it good? I guess that the Object Oriented Paradigm is so well established now that we can do things like this in the language and not expect "old skool" programmers to immediately break things with it.

Hibernate3 is not EJB3

My first and most painful lesson in my year with J5EE was about Hibernate, Hibernate3, annotations, and EJB3. I had been lead to believe by an evil leprechaun that EJB3 was just Hibernate. I learned by actual experience in creating applications that this is simply not true. In fact EJB3 is a standard that Hibernate3 implements.

Why is that an important distinction?

Because EJB3 features are a proper subset of Hibernate3 features since Hibernate "embraces and extends" the EJB3 standard. It also means that if you do intend on using those cute little "at" signs in a "portable" way you'll have to figure out what EJB3 annotation to use to solve the Hibernate trace you just saw.

EJB3 doesn't require XML sit-ups and the EJB3 implementation in JBoss that sits on top of the Hibernate3 layer hides those gut busting crunches from your beady little eyes. So using the EJB3 persistence feature is far less painful than using the Hibernate 2 XML workout routine. That would typically mean that you'd want to use the EJB3 model whenever possible.

The problem is that Annotations for persistence and XML for persistence can get into fistycuffs. If you set up a Hibernate SessionFactory (even if it's a version 3 session factory) you may use XML docs _or_ annotations... theory may say otherwise but when I sat down to mix my annotated classes with XML configured classes the programmatic changes to the configuration wouldn't stick.

Hibernate3 is not EJB3.

A year with Java 5 EE

I've spent the last year with Java 5 Enterprise Edition betas and I'm going to talk about my experiences with the Java environment as a relative newcomer to the Java landscape. My background is in C/C++ System V programming on Linux, Solaris, and Irix systems. It has been a hard year but one that I'm thankful for. I've learned a lot about how Service Oriented Architectures go together, why they work, and why they fail.

DWR POJO as a front controller for a WebService

In the past I would have written my own JavaScript using XmlHttpRequest and a servlet on the back end. This means I have to maintain a lot of code that has nothing to do with my specific project. I evaluated several Ajax frameworks and settled on DWR for my current project. But I have a problem.

I've been writing a DWR object to act as a front controller to a web service. As I wrote previously when using DWR you write a POJO. Register the POJO in dwr.xml and the annotations take care of the rest. But, what about request scope parameters? The request is gone by the time my POJO is called...

http://getahead.ltd.uk/dwr/server/javaapi

We use the WebContextFactory to pull out context data.

@annotations

In case you've been under a rock... Java 5 now has a feature called the annotation and it allows you to attach meta-data to a class or a method. This isn't too terribly exciting unless you write a class that can read these annotations. Official docs here. So what I've found you end up doing is writing a proxy or mediator to handle how the annotated classes are used, what the annotations mean, and how the classes interact.

I'm using DWR at the moment and when we write a POJO and annotate it with the right annotations we get a class that DWR can use to create JSON messages. DWR searches a registered POJO for the "@RemoteMethod" annotations and registers those methods for remote invocation. This is very similar to how the JBossWS system works.

In both DWR and JBWS we are using annotations on POJOs to mark the class and method for consumption by a larger framework that will use the method we wrote to form the unique functional core of an application. We can tell the framework some things about how to consume the method and class using the annotation... and we can use the same POJO in multiple frameworks... in theory.

In theory the same annotations could mean different things to different frameworks. This way a POJO could be fed through a testing tool and then fed to a Web Services framework. The key to using the annotations is that the consuming tool, library, or framework sits across concerns from the POJO.

You POJO should be concerned about one thing, such as how to build an item summary. Your POJO then plugs into the framework. The result is that you program what is unique about your application and forget about everything else.

In designing tools, libraries, or frameworks to consume annotations, consider what is always the same. Write your framework to do those things. Then you register POJO into your framework to do the unique tasks for an application.

I can see a need for about a half dozen annotations frameworks from where I sit. And I can see how a code by convention system could be obsoleted by the astute use of annotations. If the framework is built intelligently, Java 5 could become the fastest and simplest way to build applications because so many concerns could be lifted from the application programmer's shoulders by use of Annotations and well-designed AOP.