A Programmer's Blog

Java versus Google Go - Part 2

2010-05-23T01:38:00.003+01:00

The new Go Programming language from Google is very interesting because it attempts to bring to the world of compiled languages some of the benefits of the VM based languages, such as garbage collection and dynamic interfaces. I am considering porting one of my projects to Go, but before diving in, I would like to explore Go by writing a few small programs and comparing these with the Java versions.

Without further ado, here is a very simple program that reads a file and outputs lines to the console. First, lets look at the Java version:

package org.majumdar;

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
import java.io.Reader;

public class CatFile {

        public static void main(String[] args) {
                if (args.length == 0) {
                        usage();
                        return;
                }
                BufferedReader reader = null;
                try {
                        reader = new BufferedReader(new FileReader(args[0]));
                        String line;
                        while ((line = reader.readLine()) != null) {
                                System.out.println(line);
                        }
                } catch (Exception e) {
                        System.err.println("error: " + e.getMessage());
                } finally {
                        close(reader);
                }
        }

        private static void close(Reader reader) {
                if (reader == null)
                        return;
                try {
                        reader.close();
                } catch (IOException e) {
                }
        }
 
        private static void usage() {
                System.out.println("usage: CatFile ");
        }
}

Now, the same program implemented in Go:

package main

import "fmt"
import "os"
import "bufio"

func usage() {
        fmt.Printf("usage: catfile \n")
}

func main() {
        if len(os.Args) < 2 {
                usage()
                return
        }
        f, err := os.Open(os.Args[1], os.O_RDONLY, 0)
        if err != nil {
                fmt.Printf("error: %s\n", err)
                return
        }
        defer f.Close()
        r := bufio.NewReader(f);
        for {
                line, err := r.ReadString('\n');
                if err == os.EOF {
                        break
                }
                if err != nil {
                        fmt.Printf("error: %s\n", err)
                        break
                }
                fmt.Printf("%s", line);
        }
}

I am really not sure which one of the two is more readable.

The main differences in the two programs are in how errors are handled, and how resources are cleaned up.

Java offers the finally clause in a try block for cleaning up resources; the Go approach is to allow functions to be scheduled to be invoked when the enclosing function returns via the defer statement. The Go approach doesn't offer much programmer control over when the cleanup should occur. With a try block, the placement of the cleanup code is more under the programmer's control.

Error handling in Java is based upon exception management. Go doesn't have exception management yet; although some form of exception management is planned. The authors of Go seem opposed to exception handling as a mechanism for error handling; their argument is that the try-catch-finally construct makes the code convoluted and that encourages programmers to label ordinary errors as exceptions. My personal preference is for the Java approach because it forces you to handle the error condition. By convention in Java (although the language does not enforce this), error conditions are indicated via exceptions and not by return values.

I think with either approach you can write bad code that doesn't handle errors properly. In Java, you can do this by handling the exception incorrectly; in Go, if you forget to check for an error condition, the program will probably fail at runtime in an unexpected way.

My initial thoughts are that I prefer the try-catch-finally approach to the Go approach, both for error handling and for resource cleanup. Of course the Java approach isn't perfect; for example, the usefulness of checked exceptions is doubtful, and there could be better support for resource cleanup - in fact this is coming in Java 7.

The programs listed above are trivial, and the comparison is not really fair as the strengths and weaknesses of the two languages are not clear. I am hoping to compare two additional programs - a simple TCP/IP server implementation, and a Lock Scheduler implementation. I have the Java versions of these, and am hoping to write the Go versions in the next few days.

Testing concurrent programs

2010-04-02T02:08:00.000+01:00

Testing concurrent programs is particularly hard, as the interleaving of multiple threads of execution greatly multiples the number of possible code and data access paths. It is quite challenging to write test cases that properly test such scenarios, usually only a handful can be tested.

A unique tool that helps with testing for concurrency bugs is an IBM product named ConTest. ConTest does not generate any new test cases, but if you already have multi-threaded test scenarios, it increases the likelihood of bugs being triggered by introducing random pauses in thread execution.

A while ago, I tried running ConTest against my test suite for SimpleDBM; I found that execution had slowed considerably. So expect your test cases to take much longer to complete.

Global Loggers

2010-03-28T23:50:00.000+01:00

It seems that all existing logging libraries assume that you want a single global Log Manager, tied to the class loader. Only static methods are provided to access the Log Manager or Logger instances.

I have been rigorously removing all static objects from SimpleDBM, so that the entire object graph of SimpleDBM is rooted in the main Server object. Doing this not only makes the code more robust, it also allows multiple instances of SimpleDBM to coexist in the same classloader without conflict. But where this model has broke down is in the Logger implementation, which is a wrapper for either Log4J or JDK Logging, and neither of these allow non global instances of the Log Manager.

Much as I would loathe to do this, it seems the only solution is to roll out my own ...

Is anyone else facing this issue?

Life is too short

2010-03-28T16:59:00.000+01:00

Life is too short to be able to master multiple programming languages and tools. So while I would love to learn the new Go Programming Language, Python, AJAX, and a few other cool new things, I keep going back to what I already know, the Java programming language. I can write a small utility faster in Java than if I wrote the same utility in Python; not because Java is particularly productive, but because I do not have to spend time figuring out how to do something in Java.

This is where I think something like the Google Web Toolkit is a Godsend for someone like me. Being able to create a web user interface in Java, without having to know the intricacies of AJAX, JSP, Java Server Faces, etc. is way too cool. Of course, there is a learning curve here too, but it is a less steeper curve because the language is already familiar.

I am using GWT to create a small application to demonstrate the use of SimpleDBM. I am just loving the experience. Kudos to the Google team for coming out with GWT!

Java versus Google Go

2010-03-21T23:42:00.001Z

An interesting new systems programming language was announced by Google at the end of last year - The Go Programming Language (www.golang.org). Is this what Java should have been?

Go is of course new and old. It is a new language that derives a lot from the past work done by its creators at Bell Labs. You can even see copyright notices from Plan 9 etc. all over the place. Therefore although the language is new, it is built upon years of experience.

In general I like the new language. Two features are particularly nice:

Any object can be cast to an interface as long as the object implements the signature of the interface (sorry for using Java terminology here).
Go routines are cool as it overcomes the problem that equating a thread with a process flow creates. In other languages, if your thread blocks, your program halts. In Go, a routine that is blocked is moved out and some other routine takes it place on the thread. This will be very good for servers that need the ability to multiplex processing over a limited set of threads.

There are a few ugly things too. My dislikes are the built in allocation functions new() and make() and the pointer type. Why this mess? Java is so neat you either have primitives or references. References are like pointers except that you cannot do any pointer operations with them.

The top feature that is missing is an exception handling mechanism. I have programmed many years in C and now in Java, and I can tell you that it is far easier to create robust error handling in Java. Of course, checked exceptions were a mistake (I have changed my mind about them) and I think Go should avoid them.

I wish I had the luxury of rewriting SimpleDBM in Go. It would be an interesting and fun thing to do. But I have better things to do... I am hoping that I can at least create a network client in Go, so that it is possible to talk to the SimpleDBM server from Go.

Java on Mac OS X

2007-12-04T22:44:00.000Z

I posted elsewhere that I now own an iMac and am doing most of my Java development on it. The big problem with Java on Mac is that the JDK is pretty out of date. The official version that comes with Mac OS X 10.4 Tiger is 1.5.0_07. This version seems buggy, as the JVM seems to hang when running test cases for one of my projects. I was getting quite frustrated, and in the end decided to run my test cases under OpenSolaris, which I installed as a VM using VMWare Fusion.

Fortunately, Apple has recently made available a pre-release version 1.5.0_13 from its Developer Connection web site. You need to be registered to be able to download this release. The good news is that it fixes the bug that was causing my tests to hang the JVM. I think it has something to do with the java.util.concurrency classes. Ofcourse, if you don't use these, you would not have faced the problems I was facing.

The long gap between the Java releases on Mac seems unacceptable, especially since the JDK is so buggy. The other problem is the lack of support from major vendors for the Mac platform. I would have liked to install and use IBM WebSphere and Rational products on my Mac, but it isn't amongst the supported platforms. Linux has much better support now-a-days.

Fast forward

2007-12-04T22:26:00.000Z

It has been sometime since I last blogged about general programming topics. My day job has kept me from the joys of exploring the JPA. But many other things have happened to me in the meantime, life just goes on, and there is never enough time to catch up on everything.

For a start, I want to retitle this blog, by removing the Java from it. Let this just be a Programmer's Blog.

Creating Oracle DataSource in Glassfish

2006-05-07T01:00:00.000+01:00

To setup an Oracle Datasource in Glassfish, follow these steps:

1. Copy the Oracle JDBC drivers to /glassfish/domains/domain1/lib/ext directory. You may need to change the directory /glassfish/domains/domain1 to match your installation of Glassfish and the domain name.

2. Start Glassfish.

3. Login to the admin interface and create a JDBC Connection Pool.
Delete all properties, and add following properties:
user - set this to Oracle userid
password - set this to Oracle password
URL - set this to the URL, example jdbc:oracle:thin:@localhost:1521:xe.
xa-driver-does-not-support-non-tx-operations - set this to true.
Test the connection pool using ping.

4. Create a JDBC DataSource using the Connection Pool.

Oracle JDeveloper as JSF Editor

2006-03-29T23:19:00.000+01:00

After trying out various IDEs for editing Java Server Faces (JSF) files, I have finally settled on Oracle's JDeveloper as the best tool for the purpose. I had assumed that JDeveloper would insist on using ADF, but found to my pleasant surprise that it also allows you to design standard JSF pages in a visual manner. Unlike Sun Java Studio Creator which creates its own backing bean class, JDeveloper gives you full control, and lets you decide whether you want all/some/none of your UI components to be in your backing bean.

The Java IDE marketplace is such that no single tool meets all your needs. I find Eclipse is good for general purpose Java programming but not much use for J2EE stuff. Netbeans doesn't work for me - I have tried to use it several times but each time I have given up in frustration because I either cannot resolve some wierd error, or cannot get the IDE to do something simple. To give you an example, I try to edit a JSF file in Netbeans, and it will show code completion for jsp tags, but not for JSF. I don't have the time to work out why.

Servlets and dependency injection

2006-03-09T10:33:00.000Z

There is a very useful thread at the Glassfish discussion forum on the why it is not a good idea to use dependency injection to obtain references to EJBs or EntityManagers in Servlets.

Remote or Local interface?

2006-03-09T01:06:00.000Z

EJB 3.0 takes away much of the pain associated with maintaining the Local and Remote interfaces for Session Beans. However, there are still some issues that you need to be aware of.

By design, the EJB specification disallows the same Business interface to be marked as @Local as well as @Remote (this restriction has been added in a revision to the PFD). The reason for this is that remote interfaces have different semantics to local interfaces, and it is usually inappropriate for the same method to be exposed as a remote interface as well as local interface. The problems are two-fold:

1. Remote interfaces must typically be designed to be coarse-grained.
2. Remote interfaces do not support the pass-by-reference semantics of parameter passing as in local interfaces.

Having separate Remote and Local interfaces forces designers to think about how the interfaces will be used and ensure that the design is optimised for the use case. It also reduces the chances of errors caused by incorrect semantics, such as clients relying upon ability to pass parameters by reference.

A drawback to this approach is that it does not allow transparent redeployment of an EJB from a co-located environment to a distributed environment or vice-versa. While such re-deployment has its dangers, there are times when it can prove useful to have such a facility.

Ideally, you should define your Session beans to have either remote or local interface. This will keep the design simple and allow you to implement Business Logic as POJOs.

If you do want to endow the same Session Bean with both remote and local interfaces, then, I suggest that you use the following example as a model:

public interface CustomerService {
    
   void createCustomer(District d, Customer c);
   void removeCustomer(Long id);
   List findByDistrict(District d);
    
   @Remote 
   public interface IRemote extends CustomerService {
   }

   @Local 
   public interface ILocal extends CustomerService {
   }
}

Note that the local and remote interfaces extend a common business interface. Also note that the local and remote interfaces are nested within the business interface. I like this model because it reduces the clutter, keeps related interfaces together, and eases understanding.

When using dependency injection, you can specify explicitly whether you want the remote or local interface. For example:

@EJB(beanInterface=services.DistrictService.IRemote.class)
public final void setDistrictService(DistrictService districtService) {
   this.districtService = districtService;
}

I also suggest that when specifying dependency injection, always annotate your setters rather than instance variables. This will allow you to use your beans outside the J2EE container, for example in a Spring Framework environment.

EJB 3.0 Packaging - Entities

2006-03-09T00:43:00.000Z

I am looking at the various EJB 3.0 packaging options and trying to determine best practice. My first recommendation is that you should create separate projects for your entities and package your entities in independent jar files. This is important for a number of reasons.

Firstly, you will want to share your entities in multiple projects, so having them maintained independently makes it easier to share them across projects.

Secondly, the teams that define the entities are probably going to work closely with the folks that are responsible for defining the database Entity Model. It will be easier if these teams can work independently from other teams.

Last but not least, it is not possible to define Entities in a portable manner. The main portability issues are with the way Surrogate Keys are generated using Sequence Generators. Having separate projects for your entities will allow you to create drop-in replacements for different database vendors. So you can have one set of entities for Oracle, another for Apache Derby, and so on. For an example of this, please have a look at the EJB3Demo project.

When you create your application archives, place the Entity jar files in the lib sub-directory within the archive. This will ensure that the entity definitions are available to all your EJBs and Web applications within the application. This article by Sahoo explains the benefits of putting your entity jar files in the lib directory.

More EJB 3.0

2006-02-23T21:27:00.000Z

For the past few days I have been working on a number of things. I shall blog about them in more detail when I have some time, but in the meantime, here is a summary:

1. Packaging issues. EJB 3.0 brings hassle-free packaging, however, it is still not easy to understand what the rules are. A discussion on packaging issues can be found here and here.

2. Semantics of merge() and persist() and how they are implemented in Glassfish is being discussed here.

3. Does EJB live up to its promise to bring POJO style programming to J2EE? I previously blogged about the fact that EJB 3.0 Entities are not really POJOs because they contain hidden semantics. See here for a discussion of dependency injection of EJBs and whether it is possible to implement Business Logic as POJOs.

Sharing attributes across Entities

2006-02-15T01:14:00.000Z

One way to share common attributes across entities is to use inheritance, and put the common attributes in a super class. Another way is to abstract the common attributes into a separate Embeddable class and then embed it within the regular Entity classes. The latter approach has been used for some of the entities in the EJB3Demo project.

The entities Customer, District and Warehouse all contain some very similar columns for storing address information. I created a new class called Address to hold this common data. The Address class is marked as @Embeddable and contains the getters/setters for the attributes. Here is an extract:

@Embeddable public class Address implements Serializable {
    String street1;
    String city;
    @Column(length=20)
    public String getCity() {
        return city;
    }
    @Column(length=20)
    public String getStreet1() {
        return street1;
    }
}

Note that the getters have been annotated using @Column - this is useful for capturing the bits that are shared across the entities.

When you embed the Address object within an Entity, you can fine-tune the column mapping. Example:

@Entity
public class Customer {
    Address address;
    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name="street1", column=@Column(name="C_STREET_1")),
        @AttributeOverride(name="city", column=@Column(name="C_CITY")),
    })
    public Address getAddress() {
        return address;
    }
}

The getter for the Address object is decorated with the @Embedded annotation. The address object can be shared amongst multiple entities, and each entity can define its own column names, etc.

When you access embedded objects in EJBQL, you use the property name in the Query statement. For example, to access the city field in Customer, you would write:

SELECT c.address.city FROM Customer c

This syntax is also used when you have relationship mappings. For example, a District belongs to a Warehouse, and hence the District object contains an instance of the Warehouse object. To access the fields within Warehouse, you would write:

SELECT d.warehouse.name FROM District d

Although one could use inheritance to model above, I prefer to use the Embeddable class option as it more accurately reflects what is happening here. A Customer is not an instance of Address - a Customer has an Address. In this situation, Has-A relationship is more natural than Is-A relationship.

EJB3Demo project

2006-02-15T01:02:00.000Z

I have started a new project at www.java.net. The goal of this project is to try out various features of Java EE 50, such as EJB 3.0, JAX-WS, JAXB, etc., and identify design/code patterns that result in:

Improved portability and reusability of code, in particular, allow Business Logic and Data Access logic to be deployed inside and outside J2EE containers.
Better separation of concerns while exploiting new persistence features of EJB 3.0.

I hope to blog about some of this stuff soon - stay tuned. In the meantime, I would welcome anyone who would like to contribute to the project.

The source code for the project is available for download from https://ejb3demo.dev.java.net/servlets/ProjectDocumentList.

Reusability of Code

2006-02-06T21:14:00.000Z

I have given up trying to get the TPCC schema work as defined, i.e., using composite keys. Glassfish at present does not support Id Generators with composite keys, which poses a problem, as it means writing extra code for generating keys. As a workaround to this issue, I have modified the schema to use surrogate primary keys.

EJB persistence design favours Entity Relationships based upon surrogate primary keys.

One of the great benefits of EJB 3.0 is that it gets rid of all the boiler plate EJB code, allowing you to code Entity and Session beans as if they were POJOs. This raises the expectation that in this new world, it should be possible to write reusable code that is environment agnostic. By this I mean that I should be able to reuse my J2EE Business Logic classes and the Persistent classes in a J2SE or Servlet Container (Tomcat) environment without having to change any code.

There is an immediate stumbling block to achieving this, however. The unfortunate decision to introduce a new abstraction for Transaction Management for J2SE environment means that tranaction management code is not portable. The first rule for writing reusable code therefore is to avoid transaction management code in your classes. I will report on other pitfalls as I progress with my attempts to create reusable code.

@GeneratedValue limitations

2006-01-26T10:52:00.000Z

When I saw that the specification of sequence generation has been separated from the @Id annotation, I thought that this meant that sequence generators can be used for any column, and not just for surrogate primary keys. This, however, does not appear to be the case, at least in Glassfish, where if you try to use a sequence generator on any column that is not defined as a surrogate primary key, you get an Exception. You cannot use sequence generators in composite primary keys either.

Update: I could be wrong here because I am getting inconsistent results. More details are in the bug report I have filed with the Glassfish team.

Mapping Relationships in EJB 3.0

2006-01-23T15:44:00.000Z

Rather than create my own schema for testing EJB 3.0 features, I decided to use the schema used in TPC-C Benchmarks. This approach has the benefit that it forces me to design an object-relational mapping for a pre-existing schema, which is probably what most developers will do in practice.

If you are designing a new schema, then bear in mind that EJB 3.0 favours a design where each table has a surrogate primary key, i.e., a meaningless numeric key that is either auto-generated or generated using a sequence. Using surrogate primary keys makes it easier to map the primary key of the table, as you can simply mark the relevant field using the @Id attribute. It also makes it easier to map relationships, as the EntityManager is able to exploit natural Has-A relationships (Composite design pattern) between objects. For example, in the TPC-C schema, an Order has a one-to-many relationship with OrderLines. This can be mapped as follows:

An Order object should contain a Collection of OrderLine objects.
An OrderLine object should have a reference to the Order that it is related to.

Given below is the relevant code:

public class Order {
  set<OrderLine> orderLines;

  @OneToMany(mappedBy="order")
  public Set<OrderLine> getOrderLines() {
    return orderLines;
  }
}

public class OrderLine {
  Order order;

  @ManyToOne
  @JoinColumn(name="OL_O_ID", referencedColumnname="O_ID")
  public Order getOrder() {
    return order;
  }
}

An important point you must note here is that the OrderLine Entity does not contain an explicit field for the foreign key column "OL_O_ID" that references the primary key column "O_ID" in Order; the Persistence Engine automatically uses the appropriate field from the Order entity when inserting rows in the OrderLine table.

The situation becomes more complex when tables are not designed to use surrogate primary keys. In this scenario, it is often necessary to use composite primary keys.

I will use the Customer and District entities as examples because both have composite primary keys and there exists a many-to-one relationship between a Customer and a District. First of all, let's recall that to map a composite primary key, we need to create a primary key class that identifies the fields that form part of the composite key. This primary class is then associated with the Entity using the @IdClass annotation. The Entity itself also contains the fields used in the primary key; these are annotated using @Id and @Column. Since I described how this works in my previous post, I will only show the resulting key fields in the Customer entity here:

@Entity
public class Customer {

  @Id
  @Column(name="C_ID", nullable=false)
  public int getCustomerId() {
    return customerId;
  }

  @Id
  @Column(name="C_D_ID", nullable=false)
  public int getDistrictId() {
    return districtId;
  }

  @Id
  @Column(name="C_W_ID", nullable=false)
  public int getWarehouseId() {
    return warehouseId;
  }
}

Now in order to map the relationships, we add the following:

@Entity
public class Customer {
  District district;

  @ManyToOne
  @JoinColumns({
    @JoinColumn(name="C_W_ID", referencedColumnName="D_W_ID"),
    @JoinColumn(name="C_D_ID", referencedColumnName="D_ID")
  })
  public District getDistrict() {
    return district;
  }
}

@Entity
public class District {

  Set<customer> customers;

  @OneToMany(mappedBy="district")
  public Set<customer> getCustomers() {
    return customers;
  }
}

The problem is that now there are two ways of updating the foreign key columns in the Customer entity, because the foreign key columns are present in the referenced District entity, but also present as fields in the entity in order to satisfy the requirements for a composite primary key. If you try to execute this code, you will encounter an Exception such as this (in Glassfish):

Multiple writable mappings exist for the field [TPCC.CUSTOMER.C_W_ID]. Only one may be defined as writable, all others must be specified read-only.

Multiple writable mappings exist for the field [TPCC.CUSTOMER.C_D_ID]. Only one may be defined as writable, all others must be specified read-only.

To resolve this problem, you need to modify the Customer Entity definition and ensure that the columns TPCC.CUSTOMER.C_W_ID and TPCC.CUSTOMER.C_D_ID are marked as readonly, by setting insertable=false and updatable=false:

@Entity
public class Customer {

  @Id
  @Column(name="C_D_ID", nullable=false,
          insertable=false, updatable=false)
  public int getDistrictId() {
    return districtId;
  }

  @Id
  @Column(name="C_W_ID", nullable=false,
          insertable=false, updatable=false)
  public int getWarehouseId() {
    return warehouseId;
  }
}

EJB 3.0 Entities are not POJOs

2006-01-19T23:17:00.000Z

Contrary to appearances, EJB 3.0 Entities are not POJOs as they contain hidden data and functionality in order to implement some of the specification requirements. I found this out when I was stepping through some code and out of curiosity, inspected the entities returned by the EntityManager.

When you implement two Entities that are related, for example, in a one-to-many relationship, you typically have a Collection class in the first entity that contains references to instances of the second entity. For example, an Order entity may contain a Collection of OrderLine entities. EJB 3.0 supports "lazy fetches", which means that the data for the Collection is not fetched until required. To support this, the Collection class contains extra functionality and data - you can see this if you inspect the Entity using a debugger. When you try to access the collection, this hidden functionality is triggered; and data is fetched to populate the Collection. This process carries on recursively for all referenced entities.

Lazy fetching is clearly desirable because you do not want data to be unnecessarily fetched if you do not intend to use it. However, the problem is that the Entity is not fully initialized until all the data is fetched. This poses a particular problem if you want to use the Entities outside of their "managed" environment. Any attempt to access the uninitialized data may fail. Section 3.2.4 of the EJB 3.0 specification (PFD) spells out exactly what you can safely access.

See the recent thread at the Glassfish Discussion Forums on this issue, and how it affects client access.

One of the questions that will be debated in future is whether EJB Entities should be exposed outside the Data Access layer. For example, should you expose entities in your Business Logic interfaces, or to your clients. Since EJB 3.0 Entities are touted as POJOs, many developers will assume that they can use these objects ouside of the Data Access layer. However, such use is fraught with danger, due to the semantics of detatched entities.

In my view, the EJB specification should require that detached entities are "cleaned" and made POJOs. This would lead to more predictable behaviour, and less surprises.

Some comments on EJB 3.0 PFD

2006-01-17T13:27:00.000Z

In a previous post, I complained about lack of clarity in the specification of the @IdClass annotation. Well, it seems that this lack of clarity extends to anything to do with composite primary keys. Here is what the specification has to say about composite primary keys:

Composite primary keys typically arise when mapping from legacy databases when the database key is comprised of several columns.

Perhaps this explains why there aren't any real examples to show how Entity relationships ought to be mapped when composite primary keys are involved.

@GeneratedValue annotation support in Glassfish

2006-01-16T13:31:00.000Z

I reported previously that Glassfish does not yet support the new @GeneratedValue annotation specified in the EJB 3.0 PFD. I downloaded the latest build ( b33) of Glassfish today, and while testing my code, found that the new build supports @GeneratedValue. It is a pity that one has to find this out by trail and error; the Glassfish team should put up some release notes with each build which covers feature changes since last build.

Anyway, the old syntax for @Id annotation allowed atributes for specifying Id Generators. The new method requires the Id Generator to be specified separately using a @GeneratedValue annotation. Here is a comparison between the old approach and the new approach:

Old approach:

@Id (generate=GeneratorType.SEQUENCE, generator="SEQ_GEN") 
public Long id;

New approach:

@Id
@GeneratedValue(strategy=GenerationType.SEQUENCE, 
  generator="SEQ_GEN")
public Long id;

I think the new approach is cleaner. It also enables Id Generator to be used in fields that are not necessarily the primary key.

Overall, the fact that Glassfish seems to be following the draft specification closely is great, as it enables developers to get familiar with the new technology. Thankfully, the specs are now close to final version, so changes ought to be relatively small.

Talking of changes, I hit another one. The syntax for @TableGenerator has changed. The table is not longer specified using @Table, instead, table and schema are ordinary string attributes. Here's an example of the new syntax:

@TableGenerator(name = "DISTRICT_ID_SEQUENCE", 
   table = "IDGENERATOR", schema = "TPCC", 
   pkColumnName = "SEQ_NAME", valueColumnName = "SEQ_COUNT", 
   pkColumnValue = "DISTRICT_ID_SEQUENCE", 
   allocationSize = 10)

Regarding EJB 3.0 Entity lifecycle

2006-01-12T11:08:00.000Z

EJB 3.0 Entities exist in one of 4 states: new, managed, detached, and removed.

The state transitions of an Entity depend upon the type of operations on the Entity and the life-cycles of associated Persistence and Transaction Contexts.

When an entity is first instantiated using Java new operator, its state is "new".

If you obtain an entity instance via EntityManager.find() or EntityManager.getReference(), or through a Query, its state depends upon whether there is an active Persistence Context or not. If there is one, then the Entity is in "managed" state, otherwise in "detached" state.

When you invoke EntityManager.persist() on a "new", "managed" or "removed" Entity, it becomes "managed". Note that you cannot invoke persist() on a "detached" Entity.

When you invoke EntityManager.merge() on a "new" or "detached" Entity, a "managed" copy of the Enity is created. You cannot invoke merge() on a "removed" Entity. Invoking merge() on a "managed" Entity leaves it in "managed" state.

When you invoke EntityManager.remove() on a "managed" Entity, its new state becomes "removed". Attempts to remove "new" or "removed" entities are ignored, however, it is an error to try and remove a "detached" entity.

If the Persistence Context is TRANSACTION scoped, then all "managed" entities within the Persistence Context become "detached" when the associated transaction ends. If the Persistence Context is scoped as EXTENDED, then the entities remain "managed" even after transaction ends.

In terms of Entity state, "new" and "detached" states are similar in that the Persistence Context has no knowledge of such entities.

The rules governing the lifecycle of Persistence Contexts are complex; I will explore them in another post.

The EntityManager interface provides two mechanisms for persisting an Entity: persist() and merge(). The differences between these two interfaces are subtle, and in my view, a single interface would have been better and less confusing. In terms of usage, I would recommend using merge() at all times.

Using @IdClass in Glassfish

2006-01-10T12:57:00.000Z

Given below is an example of how to use @IdClass in Glassfish. Note that the primary key class must not have any members other than the Id fields, not even serialVersionUID, even though the primary key class is defined as Serializable.

@Entity
@Table(name = "WAREHOUSE", schema = "TPCC")
@IdClass(entity.tpcc.WarehousePK.class)
public class Warehouse {

    String name;
    String city;

    @Id
    @Column(name = "W_NAME", length = 10)
    public String getName() {
        return name;
    }

    @Id
    @Column(name = "W_CITY", length = 20)
    public String getCity() {
        return city;
    }

    public void setCity(String city) {
        this.city = city;
    }

    public void setName(String name) {
        this.name = name;
    }
}

public class WarehousePK implements Serializable {

    String name = "";
    String city = "";

    public WarehousePK() {
    }

    public String getCity() {
        return city;
    }

    public String getName() {
        return name;
    }

    public void setCity(String city) {
        this.city = city;
    }

    public void setName(String name) {
        this.name = name;
    }
  
    @Override
    public boolean equals(Object arg0) {
        if (arg0 == this) {
            return true;
        }
        else if (arg0 instanceof WarehousePK) {
            return name.equals(((WarehousePK)arg0).name) &&
  city.equals(((WarehousePK)arg0).city);
        }
        return false;
    }

    @Override
    public int hashCode() {
        return name.hashCode() ^ city.hashCode();
    }
}

The primary key class is useful when searching for objects by their primary key. Example:

    WarehousePK key = new WarehousePK();
    key.setName("LONDON WAREHOUSE");
    key.setCity("LONDON");
    Warehouse w = em.find(Warehouse.class, key);

When creating new entities of updating existing entities, you should access the properties within the entity as normal. Example:

    Warehouse w = new Warehouse();
    w.setName("LONDON WAREHOUSE");
    w.setCity("LONDON");

Problems with EJB 3.0 @IdClass specification

2006-01-10T12:05:00.000Z

Note that comments below are based upon the Proposed Final Draft specification of EJB 3.0.

I feel that the specification of @IdClass is not at all clear. There are several problems:

1. It is not clear what the class that represents the composite primary key is used for.

Is it just an informative construct designed to tell the Enity Manager which fields of the Entity represent the key?

How and when are clients expected to use this class?

From trial and error and guesswork I have deduced that the class that represents primary key is essentially for two reasons:

a) First to tell the Entity Manager which fields of an Entity correspond to the composite primary key.
b) Secondly, for use in the EntityManager.find() and EntityManager.getReference() methods, as the second argument.

It is also not clearly stated anywhere whether the primary key class needs to be annotated in any manner. Clearly, if it is used as @EmbeddedId then it must be annotated using @Embeddable, but if it is used as @IdClass then no annotation is needed.

2. There aren't any examples illustrating the use of @IdClass. There are few code snippets that depict @IdClass usage, but these do not adhere to the requirements defined for primary key classes.

Section 9.1.13 shows an entity called Employee, but does not show the EmployeePK class.

Section 9.1.31 (page 190) shows a primary key class EmpPK but this class does not adhere to the rules - ie, not Serializable, and does not implement hashCode() and equals().

Using bind variables in generated SQLs

2006-01-09T11:28:00.000Z

I noticed that the generated SQLs in Glassfish/Toplink implementation of EJB 3.0 persistence, use literal values instead of bind variables. Here are a few examples:

Here is the generated SQL when creating a new entity:

INSERT INTO TPCC.WAREHOUSE
   (W_CITY, W_STREET_1, W_STREET_2, W_VERSION, 
      W_TAX, W_STATE, W_YTD, W_NAME, W_ZIP)
   VALUES ('LONDON', NULL, NULL, 1, 0, NULL, 0, 
      'LONDON WAREHOUSE', NULL)

Now, look at the SQL generated for a query:

Code:

Warehouse w = (Warehouse) em.createQuery(
   "SELECT w FROM Warehouse w WHERE w.name = :wname")
     .setParameter("wname", "LONDON WAREHOUSE")
     .getSingleResult();

Generated SQL:

SELECT W_ID, W_CITY, W_STREET_1, W_STREET_2, 
      W_VERSION, W_TAX, W_STATE, W_YTD, W_NAME, W_ZIP 
   FROM TPCC.WAREHOUSE 
   WHERE (W_NAME = 'LONDON WAREHOUSE')

Finally, have a look at the UPDATE SQL:

UPDATE TPCC.WAREHOUSE 
   SET W_STREET_1 = 'Braham Street', W_VERSION = 2 
   WHERE ((W_ID = 1) AND (W_VERSION = 1))

Clearly, the default implementation is always using literals in SQL statements. I haven't yet found a way to tell Glassfish/Toplink to use bind variables in SQLs.

Fortunately, since Glassfish and Toplink are both OpenSource, I can probably find out how to do this by looking at the source code.

Why EntityTransaction?

2006-01-09T11:06:00.000Z

When managing entities outside a J2EE container, you need to obtain an instance of EntityTransaction to manage transactions. Here is an example:

        EntityManager em = null;
        try {
            em = Persistence.createEntityManagerFactory("em1")
                    .createEntityManager();
            System.err.println("Created entity manager");
            Warehouse w = new Warehouse();
            w.setName("LONDON WAREHOUSE");
            w.setCity("LONDON");
           
            EntityTransaction t = em.getTransaction();
           
            boolean success = false;
            t.begin();
            try {
                em.persist(w);
                success = true;
            }
            finally {
                if (success) {
                    t.commit();
                }
                else {
                    t.rollback();
                }
            }
           
        } catch (Exception e) {
            e.printStackTrace();
        }
        finally {
            if (em != null) {
                em.close();
            }
        }

I would like to understand the rationale for introducing a new abstraction for transaction management when the UserTransaction interface already exists. By introducing a different mechanism for out-of-container applications, it will be harder to write code that is environment agnostic ... unless you write a wrapper to hide the differences.

Experiments with EJB 3.0 @Id annotation

2006-01-08T23:18:00.000Z

I have been messing around with @Id annotation in EJB 3.0 for generating primary keys.

Firstly, there appears to be a change in the latest version (Proposed Final Draft) of the EJB 3.0 specification which is not supported in Glassfish yet. The latest version requires a separate annotation called @GeneratedValue to define the type of Id generator. I downloaded Eclipse Dali yesterday, and this seems to support the new method.

The previous syntax supported five generator types - NONE, AUTO, SEQUENCE, IDENTITY and TABLE. In the new syntax, NONE is no longer required, as it is implied if there is no @GeneratedValue annotation. The remaining four generator types are supported.

By default, if no generator type is specified, then NONE is implied. This means that the developer must set the Id property or field correctly before attempting to persist the entity.

I have some trouble getting to terms with SEQUENCE and IDENTITY generators. Not all databases support both of these, so it seems to me that if you annotate your Entity with either of these then you are going to end up with non-portable code. My recommendation is to avoid these.

IDENTITY generator type is meant to be used when the underlying DBMS supports the IDENTITY column type - this is an autoincrement column that is maintained by the DBMS itself. For example, you can create a table in Apache Derby with a column defined as "GENERATED ALWAYS AS IDENTITY". Note that systems that support this also support a mechanism for retrieving the last generated IDENTITY value. This method is not the equivalent of using a trigger to populate the primary key - as is sometimes done in Oracle. With the trigger approach, there is no support for retrieving the last generated IDENTITY value.

The SEQUENCE generator is meant for systems that support Sequences. I know of Oracle and PostgreSQL that support sequences.

The TABLE generator, as its name implies, relies upon a special table for generating sequences. This is a portable method, as it does not rely upon native generators. Here is an example annotation that specifies a table generator:

@TableGenerator(name="IDGEN",
   table=@Table(name = "SEQUENCE", schema = "DIBYENDU"),
   pkColumnName="SEQ_NAME",
   valueColumnName="SEQ_COUNT",
   pkColumnValue="ID_SEQUENCE",
   allocationSize=10)

Finally, there is the AUTO generator type. This is meant to use the best strategy available in the DBMS. Unfortunately, Glassfish seems to insist on using a table generator, at least when I tested this with Apache Derby. It also assumes that you have created a table called SEQUENCE in the default schema for the JDBC Connection ID - there is no way to specify the schema. The expected table structure is not documented as far as I can see, but you can guess it by looking at the SQL logs. You can also use the DDL generation facility in Glassfish to get the basic DDL for creating this table.

Speaking of DDL generation facility in Glassfish, I think it is not very useful at the moment. The DDL generated looses information - for example, it does not respect any @Column attributes other than name.

On Checked Exceptions

2006-01-07T18:05:00.000Z

Here are a couple of my blogs on Checked Exceptions:

I recommend this excellent blog about Java API Design Guidelines, by Eamonn McManus. Agree with most of it except the bit about using Unchecked Exceptions. Eamonn provides a link to a presentation by Joshua Bloch, which covers the same subject.

Using Glassfish EJB 3.0 Persistence in J2SE

2006-01-05T11:31:00.000Z

UPDATED 7th May 2006
One of the great things about EJB 3.0 is its support for persistence in J2SE environments. This is great for trying out various persistence features without the overhead of developing an application which must be deployed to an application server before it can be tested.

To use EJB persistence in your J2SE program, you need a couple of jar files that come with Glassfish distribution. These are:

/glassfish/lib/toplink-essentials.jar
/glassfish/lib/toplink-essentials-agent.jar

These jar files are available as a separate standlone bundle here.

You require the toplink-essentials.jar during development. At runtime, you need to add the following option to your Java command line:

-javaagent:/glassfish/lib/toplink-essentials-agent.jar

This will automatically include the toplink-essentials.jar to your classpath.

There is another preliminary step that you need to be aware of. You need to create a file named persistence.xml in a directory called META-INF. This directory must be in your classpath. Given below is an example of a persistence.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence">
  <persistence-unit name="em1" transaction-type="RESOURCE_LOCAL">
    <provider>oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider</provider>
    <class>entity.Table</class>
    <properties>
        <property name="toplink.jdbc.driver" value="oracle.jdbc.driver.OracleDriver" />
        <property name="toplink.jdbc.url" value="jdbc:oracle:thin:@localhost:1521:sample" />
        <property name="toplink.jdbc.user" value="scott" />
        <property name="toplink.jdbc.password" value="tiger" />
        <property name="toplink.logging.level" value="INFO" />
    </properties>
  </persistence-unit>
</persistence>

If you use set logging level to FINEST you can see the SQLs being generated by Toplink.

To access the EJB 3.0 EntityManager in your program, add lines similar to following:

  EntityManager em = Persistence.createEntityManagerFactory("em1")
      .createEntityManager();

EJB 3.0

2006-01-04T23:13:00.000Z

I have recently started exploring EJB 3.0. I am using the latest builds of Glassfish, Sun's OpenSource Application Server. Glassfish contains an OpenSource version of Oracle's Toplink product.

I had stayed away from EJB so far, as I was not convinced that the benefits of EJB outweighed the complexities it introduced into code. I had been looking at alternative light weight frameworks such as SpringFramework as a substitute for EJB. EJB 3.0 has however converted me. In my view, once production implementations of EJB 3.0 are available, there will be fewer occasions to use alternative frameworks.

As I learn more about EJB 3.0 and Glassfish, I will post my findings here. Stay tuned.

Hello

2006-01-04T23:08:00.000Z

This is where I intend to blog about programming in general, and Java programming in particular.