Theres more numbers in there than you think!

A BigDecimal is not a standard floating point number. Instead: it’s a binary representation of a number. This means: 0.0 != 0.00. While this doesn’t seem like a problem at first: I’ve seen it cause no-end of strange little bugs. The only way to accurately determine whether two BigDecimal objects have an equal value is by using the compareTo method. Try these two little unit tests:

@Test
public void testScaleFactor() {
    final BigDecimal zero = new BigDecimal("0.0");
    final BigDecimal zerozero = new BigDecimal("0.00");

    assertEquals(zero, zerozero);
}

@Test
public void testScaleFactorCompare() {
    final BigDecimal zero = new BigDecimal("0.0");
    final BigDecimal zerozero = new BigDecimal("0.00");

    assertTrue(zero.compareTo(zerozero) == 0);
}

This technique works when you’re in control of the data and the comparison, but it breaks when you want to put a BigDecimal object into most other Java data-structures. I’ve actually seen someone use a BigDecimal as a key to a HashMap, which of course didn’t work. The solution in this case was simple: change the HashMap for a TreeMap and things were happy. However it won’t always be this simple.

They’re true high precision structures.

This doesn’t just mean that they are precise, it also means that they won’t run any calculation that wouldn’t result in a representable answer. Take the following code snippet as an example:

@Test
public void testArithmatic() {
    BigDecimal value = new BigDecimal(1);
    value = value.divide(new BigDecimal(3));
}

Primitive numeric types would just swallow this and represent the 0.3* as best they could, while a BigDecimal throws an ArithmeticException instead of attempting to represent a recurring number. In some cases getting an error will be desirable, but I’ve actually seen someone resolve the ArithmaticException like this:

try {
    return decimal1.divide(decimal2);
} catch(ArithmaticException ae) {
    return new BigDecimal(decimal1.doubleValue() / decimal2.doubleValue());
}

Yes folks, unfortunately I’m quite serious here. This is the sort of bug introduced by an error occurring, computations stop running, and someone adds a “hack” to just “make it work quickly and we’ll fix it later“. It’s a total disaster, but I see it far to often.

They don’t play nice with Databases.

According to the JDBC spec database drivers implement a getBigDecimal, setBigDecimal and updateBigDecimal functions. They seem like a great idea, until you ponder that your database may not have a suitable storage type for these values. When storing a BigDecimal in a database, it’s common to type the column as a DECIMAL or REAL SQL type. These are both standard floating-point types, with all the rounding errors that implies. They are also limited in capacity and will often overflow or cause a SQLException when attempting to store very large BigDecimal values.

The only practical solution which will keep all the BigDecimal functionality and accuracy in a database is to type the amounts a BLOB columns. Try to imagine the following table structure if you will:

CREATE TABLE transactions (
    initial_date DATETIME NOT NULL,
    effective_date DATETIME NOT NULL,
    description VARCHAR(30) NOT NULL,
    source_id BIGINT NOT NULL,
    destination_id BIGINT NOT NULL,
    in_amount BLOB NOT NULL,
    in_amount_currency CHAR(3) NOT NULL,
    effective_amount BLOB NOT NULL,
    effective_amount_currency CHAR(3) NOT NULL,
    charge_amount BLOB NOT NULL,
    tax_amount BLOB NOT NULL
);

That required four different BLOB columns, each one of which will be stored outside of table space. BLOB objects are very expensive both to store, and to work with. Each one often uses it’s own database resources (much like an internal cursor) to read or write the value. This translates to much more time and network usage between your application and it’s database. To add to the misery a BLOB is generally not readable by a SQL tool, one of the major reasons for sticking with a SQL database is that it can be managed from outside of your application.

Performance.

This is often raised as an issue, but ignored in favor of “accuracy”. The performance of BigDecimal is often considered “good enough” for general computing, and it’s fine if you want to add tax to an item every once in a while, but consider the number of interest calculations per month a moderate sized bank do. This may seem like an extreme case, but if your application ran a simple shipping and tax calculation for items on an online store in a JSP you’ve got effectively the same problem. In a very simple multiplication test BigDecimal performed over 2300 times slower than a simple long value. While this may only be milliseconds per mutation, a performance-factor of this size very quickly adds up to more computational time than is actually available to the system.

Also remember that BigDecimal (like most Number subclasses) are immutable. That means every calculation requires a copy of the existing BigDecimal. These copies are generally cleaned away by the eden-space collector (and G1 is very good at handling them), but when you put such a system into production it leads to a massive change in your heap requirements. Your BigDecimal objects must be allocated in such a way that a minimum number of them survive a garbage collection, the memory requirement of such a space quickly spirals out of control.

To add to the performance argument: the compareTo method is quite a bit slower than the equals method, and gets significantly slower as the size of the BigDecimal increases.

A Cure to BigDecimal Woes:

A standard long value can store the current value of the Unites States national debt (as cents, not dollars) 6477 times without any overflow. Whats more: it’s an integer type, not a floating point. This makes it easier and accurate to work with, and a guaranteed behavior. You’ll notice that several different behaviors in BigDecimal are either not well defined, or have multiple implementations. That said: depending on your application you may need to store the values as hundredths or even thousandths of cents. However this is highly dependent on your application, and theres almost always someone who can tell you exactly what unit the business works in. Bare in mind also that there are often de-facto (or even mandated) standards which exist between businesses about what unit of money they deal in, using more or less precision can lead to some serious problems when interfacing with suppliers or clients.

The mechanism I generally try to use is a custom-built MoneyAmount class (each application has different requirements) to store both the actual value, and it’s Currency. Building your own implementation opens the opportunity to use factory methods instead of a constructor. This will allow you to decide on the actual data-type at runtime, even during arithmetic operations. 99% of the time, an int or long value will suffice – when they don’t the implementation can change to using a BigInteger. The MoneyAmount class also enables you to define your own rounding schemes, and how you wish to handle recursive decimal places. I’ve seen systems that required several different rounding mechanisms depending on the context of the operation (currency pairs, country of operation and even time of day). For an example of this kind of factory discussion: take a look at the source-code for the java.util.EnumSet class. Two different implementations exist: the RegularEnumSet class uses a long to store a bit-set of all the selected constants. Given that very few enum values have more than 64 constants this implementation will cover most cases, just like a long will cover most requirements in a financial system.

Summary

This post is to warn people who are busy (or about to start) writing a system that will run financial calculations and are tempted to use BigDecimal. While it’s probably the most common type used for this purpose in the “enterprise” world, I’ve seen it backfire more times than I care to recount. My advise here is really to consider your options carefully. Taking shortcuts in implementation almost always leads to pain in the long-run (just look at the java.util.Properties class as an example of this).

Recently however I’ve been using a MacBook Pro, and I’ve gone from a fanatical devotion to my Linux machine to a fondness for the Apple. I decided to write out a list of the things I’ve noticed about these machines that makes them so ideal for software development.

Note: this is really just my opinion on the subject, don’t take it to seriously

Spotlight is Productivity Defined

There are several desktop based search tools for both windows and linux, but they don’t even come close to how powerful Apple Spotlight is. If you’re used to a keyboard driven environment you’ll absolutely love it. Not only for just starting your software, but for amazingly quickly finding that document you were reading the other day… the one that said something about “too much fresh fruit”.

It’s BSD Based Underneath

Thus a flavor of Unix. Whatever Unix derivative I’ve developed on over the years, they have always been (for me) more productive than Windows. I’ve found that the single most important reason for this actually appears to be the implementation of the file system layer. Unix implementations tend to have a more robust and flexible file system implementation, while Windows seems to be of the opinion that it’s always going to be a desktop machine, and if something goes wrong you can shut it down and do a scandisk (and yes I have used Windows 7, it’s still broken).

The better file system layer plays directly into software development. Source control tools such as Subversion, databases and web servers all tend to have less problems on a Unix file system than on Windows. Yes the tools could probably be modified to better handle the Windows filesystem, but should that really be necessary?

Gesture Recognizing Touch Pad

Spend in hour or two using the touch pad on a Mac and you may find it difficult using any other touch pad. The ability to switch from scrolling to clicking to navigating without actually moving to different areas of the pad makes a huge difference.

The other thing everyone comments on, and I’ll definitely add my voice to is the size of the touchpad. It’s so huge I don’t miss a mouse in the slightest. In fact quite the opposite, I would far rather develop software with a MacBook Pro touchpad than with a mouse. Main reason: it’s much closer to the keyboard, I don’t need to move my hand over to the mouse to scroll or navigate code or documentation.

Finally (and a bit unusual maybe), the ability to smoothly scroll horizontally as well as scale (with the pinch gesture) makes viewing diagrams much easier than previously. Most touchpads emulate a mouse-wheel when they scroll, and most diagram software tends to interpret this as very slow scrolling, or scrolls in “lines”. Both of these behaviors are very annoying and effectively wrong.

The Keyboard is Incredible

It’s not just the fact that it’s a clicklit keyboard, it’s the size and spacing of the keys. The arrangement of the keyboard is similar to a desktop keyboard, but since it’s a laptop the keys don’t sink as far, they tap away with a very satisfying ”click” sound. The backlight is also brilliantly useful for late-night coding, but you can find that on many different laptops today.

The default keyboard shortcuts also make abundant sense when you’re using these keyboards. Some of the characters are not quite where you expect to find them at first, after a short time of using them I’m wondering why all QWERTY keyboards aren’t arranged like this. Finally: many of the symbols that you’d normally open a character map application for are accessible directly from the keyboard. It’ll take you a bit of time to get used to the fact that you can type a ± or Ω with just 2 keys, but it’s a brilliantly useful ability.

It’s Just Built Better

Having looked at a large number of laptops, both off-the-shelf and customized builds I’ve found that the MacBook Pro is actually surprisingly good value for money: if you know whats inside. It’s small details such as one laptop using a Core2-Duo while the same priced MacBook is an i5 CPU. Theres also the size of the battery, which for some is less important than others. If you take a look at the image on the right you’ll see just how much physical space the battery takes up in the 15″ variation of the MacBook Pro: it’s huge! It’s actual capacity is 77.5 watt-hours, compared to a similarly priced Lenovo laptop which has just 48 watt-hours.

Another “feature” is the fact that the MacBooks all have DDR3 memory in them where most of the competition is still using DDR2 (and often really cheap DDR2 at that). The MacBooks also generally have more memory by default than similarly priced machines.

Other tiny features that make a huge difference are the amazing lack of cooling vents on the case, the mag-safe power connector that simply falls away when someone kicks your cable, the battery meter on the outside of the laptop.

Add to all of this that the MacBook is generally thinner than it’s competitors and has an aluminium case instead of the normal plastic nonsense and you’ll find that the MacBook will not just out-perform it’s competition but also just feels more solid when you carry it around.

It Just Works

This sounds really corny, and it’s generally a bit of a Mac idiom, but it’s true. When I plugged my Android phone in to do some on-the-device debugging work, all I had installed with the stock Android SDK. With no special device drivers or funny setup work, the device just worked. I set breakpoints, hit them, edited variables, simply put: I controlled the phone from my MacBook with no special setup or configuration. All things considered, this is quite amazing.

In broad terms, the book covers the following aspects:

• Designing user-friendly interfaces that support quick and easy access to information
• Exploring and implement multiple layouts in Android to design user interfaces for the different screen sizes and densities
• Ensuring a consistent user-interface experience and improve your application performance by reusing your application components
• Designing easy-on-the-eye themes for your Android applications
• Displaying and select complex data structures from applications such as an address-book or calendar application by using Android widgets
• Animating visual queues of what the application is currently doing, and what effect their actions are having
• Customizing the built-in classes in Android to enhance the user interface by creating tabs and galleries
• Learning to Leverage Android’s resource loading system
• Learning how best to present your user with information; or capture information from them

You can find more information about the book, and also pre-order yourself a copy from the Packt Publishing web-site.

Since the early days of Java 7; I’ve been a concerned Java-citizen. Java feels like it’s loosing what made it a great language in the first place. It was the first programming language I ever learned. I more-or-less self taught myself with the aid of a (now very tattered) copy of “Core Java” (first edition). Java was great because it was simple to learn, but an inherently powerful environment to work in. The language (pre 5) was kept extremely simple, with little in the way of syntactic candy. For an analogy: it was Othello; while C++ was (and is) Civilisation. Java’s true power lay in the fact that the language was extremely simple to pick-up and work with, while the platform carried you forward as you built more and more complex software systems.

With Oracle now at the helm of Java; and the community drowning while trying the hold onto the rudder: I finally think that a fork of the code-base; and more importantly the specification is in order. The idea of forking Java makes me very sad; it’s got a special place in my heart (much the way Sun did as a company). However: sometimes you need to settle for the lesser of two evils, and in this case: leaving Java in the hands of Oracle is the greater evil.

Having seen the way Google manages projects such as GWT and Android; I believe (strongly) that Google engineers are in a much better position to steer the way-forward for Java. The fork wouldn’t necessarily be called “Java” any-more; a branding overhaul would be needed to avoid further litigation from a wrathful Oracle. I also don’t believe that in individual or small community forking the code-base and specification would work; simply because they would be unable to attract the required attention.

Google already has many resources invested in Java; some of those resources in areas of Java that few people understand. I strongly feel that a Google guided fork of Java as both a language and platform would not just be in the best interests of Google; but also the best interests of anyone in the Java community.

Unit Testing has become one of the corner-stones of good software development (it has been such for quite a long time actually). However writing a Unit Test that interacts with database code (at any level) can be very challenging. The main problem being: your data should be in a “known” state when the Unit Test starts running. In the past many approaches to this problem have been taken, such as: using an in-memory database; or DbUnit. Each approach has it’s up-sides and it’s down-sides (I won’t be going into them here).

To help your unit testing along EoD SQL is growing it’s own mocking extension (currently only in Subversion however). The EoD-Mock project allows you to build mock implementations of your database connection code without any external configuration. Thats right: no dependency injection; no JNDI; no factories; nothing!

How does it work?

If the EoD-Mock JAR file is on the class-path, EoD SQL will automatically look for mock implementations of your Query interfaces instead of generating a real implementation. For example, take a simple UserQuery interface:

public interface UserQuery extends BaseQuery {
    @Select("SELECT * FROM users WHERE email = ?1")
    User selectByEmail(String email);

    @Update(sql = "INSERT INTO users (email, username, birth_date) "
    + "VALUES(?{1.email}, ?{1.username}, ?{1.birthDate})",
    keys = GeneratedKeys.RETURNED_KEYS_FIRST_COLUMN)
    User insert(User user);

    @Select("SELECT * FROM users")
    DataSet<User> selectUsers();
}

To create a Mock of this interface using EoD-Mock all you need to do is write an implementation in the same package:

public class UserQueryMock extends AbstractMockQuery implements UserQuery {

    private final List<User> users = new ArrayList<User>();

    public UserQueryMock() {
        insert(new User("joe.bloggs@nowhere.com", "Joe Bloggs", new Date(83, 3, 6)));
        insert(new User("jeff@jeffswebsite.com", "Jeff Site", new Date(76, 8, 23)));
        insert(new User("logan@murkmurk.com", "Logan Sleep", new Date(90, 4, 1)));
    }

    public User selectByEmail(final String email) {
        for(final User user : users) {
            if(user.getEmail().equals(email)) {
                return user;
            }
        }

        return null;
    }

    public User insert(final User user) {
        final long id = users.size();

        final User clonedUser = new User(
                user.getEmail(),
                user.getUsername(),
                user.getBirthDate());

        clonedUser.setId(id);

        users.add(clonedUser);

        final User idUser = new User(null, null, null);
        idUser.setId(id);

        return idUser;
    }

    public DataSet<User> selectUsers() {
        return new MockDataSet<User>(users, false, true);
    }

}

Yup, it’s really as simple as that. Now if you ask EoD-SQL for an instance of UserQuery (ie: QueryTool.getQuery(UserQuery.class)): instead of generating an implementation, it will create an instance of UserQueryMock and return that.

How much does eod-mock take care of?

• EoD-Mock will self-register as a QueryFactory with EoDSQL (but only under Java 6 and higher) if it’s on the classpath
• A “default” DataSource is provided automatically. The provided implementation throws exceptions instead of providing database access
• An AbstractMockQuery class is provided to take care of the methods declared in BaseQuery
• A MockDataSet is provided, and will attempt to behave like a real DataSet object
• QueryTool.getQuery will automatically return mocked query objects, meaning: no changes to your data-access layer

Current State

EoD-Mock is currently only available in the Subversion repository, but will be included in the next release of EoD SQL. There is no support currently for the DataIterator class, but that will no-doubt come very soon.

EoD SQL Allows for fast, simple binding between a Relation Database Query and Java objects.

Think of it as your friend that gets Hibernate or JPA out-of-your-face and lets you get on with actually writing some code.

The 2.1 release has a long list of changes behind it (which we’ve built over the last few months).

1. It’s much faster than EoD SQL 2.0 was (which in turn was faster than 1.0).
2. There are a good number of bug-fixes, making it nice and stable.
3. The 2.1 release includes batch updates
   @Update(sql=”INSERT INTO users (name, email) VALUES (?{1.name}, ?{1.email})”,batchUpdate=true)
   void batchInsertUsers(Collection users) throws SQLException;
4. GWT developers rejoice! EoD SQL can now fetch objects in any Collection type you choose!
   @Select(“SELECT * FROM users WHERE group = ?1″)
   ArrayList getUsersInGroup(long groupId);
5. Byte arrays are now considered primitive types, and get mapped by EoD SQL out-of-the-box (no custom TypeMapper required)

That’s far from an exhaustive list, and you should really go download the API and try out some of the cool new features.

Some people (myself included) have been waiting a very long time to see this feature in EoD SQL, and it’s taken a fair amount of discussion to decide how it would work. The final answer came from Bernd Rinn: allow parameters to be specified as various Collection types. So to add a list of User objects to your database:

@Update(sql="INSERT INTO users (name, birth_date, password, email) VALUES (?{1.name}, ?{1.birth_date}, ?{1.password}, ?{1.email})",batchUpdate=true)
void insertUsers(List<User> users);

Batch updates will work with any class extending Collection, or an array type. It can also be used with simple parameters:

@Update(sql="REPLACE INTO user_group_join (user_id, group_id) VALUES (?{1.id}, ?{2.id})",batchUpdate=true)
void ensureUserInGroups(User user, Collection<Group> groups);

A Batch Update is generally much faster than a series of normal update invocations, because EoD SQL will use PreparedStatement.addBatch() to build up all of the parameters on the client-side before sending all of the data to the database in one statement. It doesn’t mean it’s a single transaction, but it does mean that the database can execute all of the parameter variations before sending any data back.

So why not go download the new release and give it a try.

Bernd Rinn

• Specific Collection implementations (including those not in the standard Java API’s) can now be returned:
  

  @Select("SELECT * FROM users WHERE group = ?{1.id}")
   ArrayList<User> selectUserGroup(Group group);

• Select methods can now populate existing objects:
  

  @Select(sql="SELECT * FROM user_meta_info WHERE user_id = ?{1.id}",into=1)
  void selectMetaInfo(User user);

• Faster construction of query implementations
• Better error reporting
• Several small bug fixes

This is of course a beta release, so there may be bugs. That said the code is pretty well unit tested and should be relatively stable. One new feature not in the release (but on the way) is batch updates. Stay tuned for more information!

The one problem we have come across  with the device is trying to create keys on it using the standard Java keytool application. There are two errors you’ll almost certainly face, both in the form of a sun.security.pkcs11.wrapper.PKCS11Exception.

Error 1: CKR_ATTRIBUTE_TYPE_INVALID

This error (we found) pops up when you don’t specify the key algorithm on the command line. You need to specify “-keyalg RSA” to ensure that an RSA key (instead of the default DSA) is generated for the eToken.

Error 2: CKR_TEMPLATE_INCONSISTENT

This one is a little more nasty.  It’s not well documented, but effectively the keytool doesn’t generate signatures that the eToken’s PKCS#11 implementation likes (we couldn’t find any tool other than the eToken software that did). Under Windows you need a registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Aladdin\eToken\MIDDLEWARE\GENERAL

The key is a DWORD attribute: “TolerantX509Attributes” with a value of “1″. But what about Mac and Linux. You’ll need to look for the eToken config file: /etc/eToken.conf, then under the “[GENERAL]” section of the file add the line:

TolerantX509Attributes=1

This will allow keytool (and other PKCS#11 tools) to generate and store keypairs on your USB eToken.

A Command Line Example

keytool -v -genkeypair -keyalg RSA -alias myKey -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg /home/me/pkcs11.conf

GWT turns all of your Java code into JavaScript, but it also obfuscates everything. With this in mind, it makes serialization a bit more complex than usual. GWT generates a serializer and deserializer for each class that could be transported across the wire to an RPC service. The difficulty comes in knowing which types had code generated, and which didn’t. GWT solves this problem for itself with the Serialization Policy file, where the compiler lists all of the classes that the client code will know how to deserialize.

This however leads to another problem: what happens when something unexpected gets in the way. Hibernate is the most used, and thus most complained about when it comes to Serialization problems. Hibernate turns any Collection object into a special “lazy” implementation that will only load your data when you ask for it. All very fine and well for a server bound application, but a GWT application needs all that data up front for serialization. When GWT comes to sending that List<Message> to the client, it chokes. It knows how to serialize an ArrayList, and LinkedList (since you worked with them on the client side), but a Hibernate List or PersistentCollection is a totally unknown type, so it’s not in the Serialization Policy, so the server side throws an Exception at you.

So how does EoD SQL help with these problems? Read on to find out!

Loosing the Lazy Loading

EoD SQL  (unlike most OR mapping layers) makes no attempt to understand the internal relationships between you objects. The reason for this is that EoD SQL is technically dialect neutral, it doesn’t actually care what you put into you @Select annotation so long as it can create a PreparedStatement and populate it with parameters. This frees you to take maximum advantage of database extensions, or weird SQL dialects. It also means that EoD SQL will never generate any SQL code for you: what you type is what gets executed.

Within a GWT application, you don’t have a way to block until a method is complete, and thus lazy-loading data becomes a chore, since you need to work with a lot of callbacks (a nice way of abstracting lazy-like-loading is posted on my blog). This means that most of the object model given to GWT needs to be (at least partly) eager-loaded.

So because EoD SQL doesn’t do any lazy-loading, it “forces” you into thinking about how much data and what data you will be sending to the client. It takes a little getting used to, but over time you will find your code much clearer to read and running much faster (since less data comes from the database, fewer queries are run and the JavaScript has less data to deal with).

Arrays instead of Collections

The first trick to working with GWT is: when you need more than one object fetched from the database (which is most of the time), return an array instead of a Collection:

public interface MessageQuery extends BaseQuery {

/*
* This is not a great way to do things in EoD SQL 2.0 when dealing with GWT.
* This method will return an ArrayList of Message objects, however the List implementation could
* possibly be changed in the future (not likely). Further the ArrayList is populated using the basic
* List.add(Object) method. The ArrayList will re-copy it's internal array over-and-over again as
* the ResultSet is scanned.
*
* So while this method will work with GWT, it's really not recommended.
*/
@Select("SELECT * FROM messages WHERE parent_id = ?1 ORDER BY date DESC LIMIT ?3 OFFSET ?2")
List<Message> selectChildMessagesAsList(int parentId, int start, int count);

/*
* This won't work at all with GWT. The DataSet may offer lazy-loading
* and some other wonderful tricks, but since the client code has no idea
* how to deal with a DataSet it's useless here. I thought I'd put it in for completeness.
*/
@Select("SELECT * FROM messages WHERE parent_id = ?1 ORDER BY date DESC LIMIT ?3 OFFSET ?2")
DataSet<Message> selectChildMessagesAsDataSet(int parentId, int start, int count);

/*
* This is the way to do it! Using only arrays for Serialization has a side effect
* on the GWT side of things: less JavaScript code for your clients to download.
* GWT understands how to deserialize arrays, and doesn't need to include
* Serialization code for different List implementations.
*/
@Select("SELECT * FROM messages WHERE parent_id = ?1 ORDER BY date DESC LIMIT ?3 OFFSET ?2")
Message[] selectChildMessagesAsArray(int parentId, int start, int count);

}

Now for the big question: why are arrays “so much better” than a List of some sort? EoD SQL takes fairly extreme measures to keep the performance of an Array as fast as possible. For the most part (that is: on most JDBC drivers) the array will be pre-sized and fetched backwards. This sounds very strange, but it is generally a lot faster than trying to work forwards and re-growing the array whenever it runs out of space (and then down-sizing it at the end). EoD SQL will run forwards if the JDBC driver requires it, but for the most part it runs backwards.

This technique will not only improve performance, JavaScript size, and simplicity of the code (arrays are just easier in most cases); it’ll also reduce the amount of memory your server uses (since the array is pre-sized and never copied).

Finally: because the type is declared as an array, you know exactly what Serialization code GWT is going to generate.

Looking to the Future (EoD SQL 2.1)

In EoD SQL 2.0 you can declare Collection objects as return types, but only as their interfaces (as you saw in the above code example). EoD SQL 2.1 has a new feature which allows you to declare concrete implementations as return types. This is the preferred method of declaration for GWT (since again: it minimizes the amount of JavaScript generated). A few nice little examples:

public interface MessageQuery extends BaseQuery {

@Select("SELECT * FROM messages WHERE parent_id = ?1 ORDER BY date DESC LIMIT ?3 OFFSET ?2")
ArrayList<Message> selectMessages(int parentId, int start, int count);

@Select("SELECT title, date, author FROM messages WHERE parent_id IS NULL ORDER BY date")
MyCollectionImplementation<Message> selectTopLevelMessages();

}

The big difference between 2.0s handling of Collection objects, and 2.1 is that 2.1 will allow the Collection implementation (including those declared as their interfaces) to optimize their fetching of the data internally (if they are able). Thus returning a List or ArrayList will no longer cause the resize-resize-resize effect (or shouldn’t anyways). Collections will be given the same treatment as arrays in 2.1.

Conclusion

So we’ve looked at four different situations where EoD SQL works really well.

The concept to take away from this (I feel) is that: with EoD SQL you are in total control of how the code is going to behave.

If you need lazy-loading and scrolling data (like in our Swing example), you can use a DataSet; to minimize memory a DataIterator; and when lazy-loading can’t be used because of other constraints Collections and Arrays are available. Whatever the situation: EoD SQL is going to make life that little bit easier for you, without you giving up control of what goes on behind the scene.