Before diving into Scala, I would highly recommend learning more about functional programming. A great read is Functional Programming For The Rest of Us. This is a great introduction to functional programming, and IMO, a good place to start for those of us new to FP.
After this I’d recommend Roundup:Scala for Java Refugees.
This is a six-part series and I would read through all of them.It has great side-by-side examples of both Scala and equivalent(if any) Java code.

What’s great about Scala is the flexibility to structure your code intuitively. Reading an introductory article might not always make this obvious. As a quick example, (based on a similar one in Part 6), you could add a method to any class to save itself to the database (as opposed to looking up a DAO in your service code).

class Person(firstName: String, lastName: String) {
//simple person class
}
//define a Persistent Object
class PersistentObject(obj:Object) {
def save() {
// call a DAO etc println("Saving : "+obj)
}
}

//implicitly convert a POJO to a PersistentObject
implicit def pojo2persistent(obj:Object) = new PersistentObject(obj)
new Person("Ron","Francis").save()

Next on my list: Actors-The other concept probably new to Java programmers are Scala Actors. Actors provide Erlang style concurrency( or Message Passing concurrency, as opposed to Java’s shared state concurrency). Here is an actor tutorial . I haven’t explored this yet – but sounds promising. For example, here is an interesting blog about Scala Actors and comet

In one of my earlier engagements, we were using Hibernate to map a complex graph of objects. Not only did we need to test whether the usual CRUD operations worked with one object in isolation, but with entire graphs of objects. For example, deleting a customer record should delete all records from customer_orders, customer_contacts etc.

We wrote our integration tests using JUnit. To avoid cluttering the database, we used a strategy where we explicitly started a transaction in our setUp() method and rolled it back in tearDown(). The code was (somewhat) like this:

 protected void setUp() throws Exception {
    session = HibernateSessionFactory.newSession();
    transaction = session.beginTransaction();
 }
 protected void tearDown() throws Exception {
    session.flush();//fire all sql updates..
    transaction.rollback();
    HibernateSessionFactory.endSession(session);
}

In a later engagement, we came across the same problem. However, this time we were using the spring framework. The spring framework provides a class named AbstractTransactionalDataSourceSpringContextTests (Yes, the name is a mouthful). As the name suggests, this is a abstract class you can extend your (JUnit) test case from. It comes with all the usual spring auto-wiring capabilities, in addition, it automatically rolls-back the transaction at the end of each test. Regardless of the approach, integration test are a big time saver. I usually advocate integration tests for all methods invoked from a Controller (e.g.Struts Action). Having tests such as these in place makes it possible to test and debug almost all bugs right from the IDE. And thanks to the auto-rollbacks – without making a mess of test data.

The OPTIMIZER_MODE initialization parameter in Oracle 10g influences whether the query is optimized to retrieve the first rows as soon as possible (first_rows) or all rows (all_rows). The default in 10g is all_rows.

For OLTP systems (most web applications I worked with have fallen under this category), “first_rows” usually makes sense. For example, displaying paginated results like the first 10 of a 1000 records.

However, if your database is used by clients other than your application(for example a reporting client), changing the default OPTIMIZER_MODE might not be a good option.

This was the case with our application where we needed both:

• A paginated RIA grid where first_rows made sense.
• An offline reporting server where all_rows made more sense.

One option was to go back to every query that needed “quick results” and add the SQL hint /* first_rows(n)*/. For example,

select /*+first_rows*/ last_name, first_name from Customer...

This seemed like a lot of work. Also, if you’re using Hibernate HQL, you cannot insert hints into the generated SQL.The other option is to execute the following statement prior to running the query(s).

ALTER SESSION SET OPTIMIZER_MODE='FIRST_ROWS';

However, this would also mean a lot of changes to existing code. Also, because we were using connection pooling, I’d rather execute this only once when a connection is established, and not with every query.Since we were using WebLogic Server 9.2 , we were able to take advantage of a connection pool property called “Init SQL”.(Under DataSource>Connection Pool>Advanced in the WebLogic console). This property can be set to a SQL statement that would be executed by WebLogic when the connection is initialized. We set this to :

SQL ALTER SESSION SET OPTIMIZER_MODE='FIRST_ROWS';

This way, regardless of the Oracle defaults, we were able to customize the OPTIMIZER_MODE without having to tweak the application code or the database.

If you’re using Oracle, the general form of such a query is :

   select * from
   (
      select /*+ FIRST_ROWS(n) */ a.*, ROWNUM rnum from
          (your_query_goes_here) a
      where  ROWNUM <=:MAX_ROW_TO_FETCH
   )
  where rnum  >= :MIN_ROW_TO_FETCH;

While doing this with JDBC/SQL is easy enough-if you’re using Hibernate HQL (with the appropriate Oracle Dialect), you can also take advantage of this feature. For example:

Query q = "from Customer c order by c.lastName";
q.setFirstResult(10);
q.setMaxResults(30);
List results = q.list();

For this query to work correctly, all the time, it is important to always sort by a unique column. In the example above, “lastName” will likely have duplicate values. There is no way to guarantee the order of the returned rows unless we include a unique ‘order by’ clause. If a unique column is not available, in many cases, you can just sort by ROWID. See this article here for more on rownum.The modified HQL would look like

"from Customer c
order by c.lastName, c.rowId"

Of course, you would have to map a java property “rowId” to the pseudo-column “ROWID”.
While mapping it in hibernate, be sure to mark it as update=”false” and insert=”false”, since you cannot update the ROWID column.

1. StringUtils (org.apache.commons.lang)

   StringUtils.isNotEmpty(str): Sure beats having to do the following:

   if(str!= null && str.length() >0) {
        ----
   }

   This can be expressed simply as:

   if(StringUtils.isNotEmpty(str)){
      ----
   }

   StringUtils.isEmpty(str), StringUtils.isBlank(str), StringUtils.isNotBlank (str) have similar semantics, with intuitive handling of “null” variables.
   Check out the API docs for more time-savers.

2. ToStringBuilder (org.apache.commons.lang.builder)

   Like most others, I find it invaluable to have a well defined toString method in every class I write. This is especially true of stateful classes(domain objects, DTOs etc).
   It is painful to write code like:

   public String toString() {
       StringBuffer buffer = new StringBuffer();
       buffer.append("Last Name=").append(lastName);
       buffer.append("First Name=").append(firstName);
   }

   The quick and easy:

      return ToStringBuilder.reflectionToString(this);

   If you want to customize which fields are included/excluded, it’s still simpler than using StringBuffer:

      return new ToStringBuilder(this).
          append("firstName",this.firstName).
          append("lastName",this.lastName).toString();

   Note: There are many options available like changing the default output format, including the superclass etc. Check out the API for more details.

3. EqualsBuilder and HashCodeBuilder (org.apache.commons.lang.builder)

   Again, a really simple way to write good equals andhashCode methods:

   public boolean equals(Object other) {
      return EqualsBuilder.reflectionEquals(this, other);
   }
   public int hashCode() {
       return HashCodeBuilder.reflectionHashCode(17,37,this);
   }

   See Also: CompareToBuilder

4. Validate (org.apache.commons.lang)

   A good practice is to always ensure that arguments to a method call are correct. For example,

      public void doSomething(Long aLong, Collection aCollection){
         if(aLong == null) {
             throw new IllegalArgumentException("aLong is null");
      }
   
      if(aCollection == null  || aCollection.isEmpty()) {
         throw new IllegalArgumentException(  "aCollection is null or empty");
      }
      ---
   }

   This can be expressed more concisely:

   public void doSomething(Long aLong, Collection aCollection){
     Validate.notNull(aLong, "aLong is null");
     Validate.notEmpty(aCollection, "aCollection is null or empty");
      -----
   }

The above mentioned are but a few of the useful and elegant methods on the commons lang API. The web site is http://jakarta.apache.org/commons/lang/