Java Method Concurrency

I suppose I never quite understood how concurrency works with method calls, where one method is shared among threads. With objects I think I have a clearer picture.

Basically, however, I separate methods in terms of concurrency into:

1. Stateless method
   Any method that does not try to modify any shared state.  This ensures parallel calls to this method from multiple threads remain parallel.  This is regardless of the method ownership, whether it is bound to a class-instance (object) or to a class (static), or even to an enum.  I enjoy immutable programming (to extreme points) so this is naturally my first choice.
2. Stateful method
   This type of method normally deals with object locking, objects that serve as states and are shared among callers.  Without locking, state is indeterminate, and thus renders the purpose of state sharing useless.  Execution of this method, therefore, is bound to be sequential to the order the state lock is acquired and released.  With locking, this falls into a synchronized method (below).  Otherwise it is just not the best practice.
3. Synchronized method
   An overly generalized category for this type of method execution, but anyway.
   A method, whether wholly synchronized or having a synchronized statement, is bound to be sequentially invoked to the order its lock is acquired and released.  It is not possible for two invocations of synchronized methods on the same object to interleave [Synchronized Methods].  A regular method made synchronized will mean it is bound to its owning object instance.  In the case of a static synchronized method, the thread acquires the lock for the class object associated with the class, simulating the same behaviour as class instance-bound methods.

I would expect differences to some degree for applications running on a container using proxies to facilitate managed beans, EJB, or Spring DI.

Delicious bookmarklet from Windows Phone

Did you know that Delicious' bookmarklet also works on Windows Phone's Internet Explorer? Obviously you can't `drag` the button below.

So here's how you do it on Windows Phone IE:

1st	Go to Tools - Delicious (make sure you open it in a new tab if you're reading this article from the phone). There you will find a button in the Bookmarklet box just like the button above. Tap+hold on it, select copy link.
2nd	Open your application bar (tap on the ellipsis at the bottom of your screen) and select add to favorites.
3rd	In the Web address field, paste the link, replacing whatever was previously there. You should also change the name to something like 'Add to Delicious', which this mini guide uses.

When that's done, you can try it out by opening any web page, open the application bar, select favorites as shown below

and lastly select Add to Delicious.

Overengineering

Empty layers of abstraction that are at best unnecessary and at worst restrict you to a narrow, inefficient use of the underlying API. ― Michael Borgwardt

In the cases where we've considered things over engineered, it's always been describing software that has been designed to be so generic that it loses sight of the main task that it was initially designed to perform, and has therefore become not only hard to use, but fundamentally unintelligent. ― Darasd

It fascinates me how some people are willing to spend so much time and brainpower on the so-called "application infrastructure" they unknowingly replicate, rewrite existing frameworks--mature ones, even those they are already using; they turn a blind eye to economy of execution, development productivity, and the fact that these things often take longer than developing parts that actually fulfill the requirements.

I've recently seen many cases of over-engineering and over-tinkering.  For example my superior was recently fretting about object casting.  So basically we store our project configuration in a database table, and these configuration parameters are sometimes used as method arguments.  They also store the data type name for each parameter in the table.  And then they already do the casting during query result mapping.  And for some reason, they have a global Map of String and Object to retain the result, completely making all of that casting useless, and to use it as a method argument they have to cast it again from Object into the required type.  And he wanted to come up with generics and a layer of abstraction on top of, well, what it is I don't have the slightest clue--to "avoid object casting".  I was completely speechless.  My rationale is that object casting is unavoidable when you: 1. keep them all, of different types, as values of a single Map, 2. store them as strings in the database, and 3. use Java (in Scala you can do a type matching to avoid explicit object casting).  Although, well, now that I think about it again, this is probably not a case of over-engineering but probably leans more towards a case of uninformed engineering.

My Cassandra Templates

So I thought I would share some of my abstract adapter code for, eh, interacting with Hector client, that in turn interacts with Cassandra.

The idea is it adapts any model/entity POJO class into a key and columns that fit a column family that corresponds to the model. This happens through the marshal and unmarshal methods that are specific to each implementor of this trait. Curious names--marshal and unmarshal, but I just don't want to call them map and unmap or pack and unpack because in Scala they have different concepts. Marshal transforms the model into, really, a Scala tuple of key and list of tuples of column name and value. The persist methods in this adapter know how to work with them. Unmarshal transforms query results (in the form of ColumnFamilyResult) into the model. And this one is used by query methods.

As you can see the adapter also functions as a high-level DAO in that the user of the DAO shouldn't know about how to work with Hector/Cassandra.

Fine, I know it gets roundabout, the interaction between this trait and its subclass, but it's just how it is for now. I don't want to spend too much time refining for now.

Furthermore there is this automatic Id field finder method (getKeyFieldOpt). It does some reflection work against the model to find which field is the Id (row key). In my case Id is a case class (like var id = Id(9999)). And I think I use some implicit defs so retrieving id transforms it automatically to its value whenever relevant. But you get the gist.

This is a work in progress. At the moment all generic queries work to fetch the entire row of a column family and unmarshal its data to a model, but I'll be working on generic slices and ranges soon.

So here's the base trait:

import java.lang.reflect.Field
import scala.collection.JavaConversions._
import id.pronimo.watchlet.exception.NoExistingRowException
import id.pronimo.watchlet.exception.WrongModelException
import javax.validation.ConstraintViolation
import javax.validation.ConstraintViolationException
import javax.validation.Validation
import javax.validation.ValidationException
import me.prettyprint.cassandra.serializers.AsciiSerializer
import me.prettyprint.cassandra.serializers.StringSerializer
import me.prettyprint.cassandra.serializers.UUIDSerializer
import me.prettyprint.cassandra.serializers.CompositeSerializer
import me.prettyprint.cassandra.serializers.DateSerializer
import me.prettyprint.cassandra.service.template.ColumnFamilyResult
import me.prettyprint.cassandra.service.template.ColumnFamilyTemplate
import me.prettyprint.cassandra.service.template.ColumnFamilyUpdater
import me.prettyprint.hector.api.exceptions.HectorException
import me.prettyprint.hector.api.factory.HFactory
import me.prettyprint.hector.api.mutation.Mutator
import me.prettyprint.hector.api.Keyspace
import id.pronimo.watchlet.model.metadata.Id
import me.prettyprint.cassandra.serializers.SerializerTypeInferer
import me.prettyprint.hector.api.Serializer

trait CommonStandardCFAdapter[R <: Serializable, K, N] {
 @transient val (us, ss, as, ds, cs) = (UUIDSerializer.get, StringSerializer.get, AsciiSerializer.get, DateSerializer.get, CompositeSerializer.get)
 @transient val EMPTY_BYTE_ARRAY = Array.empty[Byte]
 @transient val validator = Validation.buildDefaultValidatorFactory.getValidator
 
 def fs[F](x:F) = { SerializerTypeInferer.getSerializer[F](x) }
 val hcolumn = (n:N, v:Any) => {
  HFactory.createColumn(n, v, getKeyspace.createClock, getNameSerializer, fs(v))
 }

 /* CONCRETE METHODS [BEGIN] */
 /**
  * Add a new record, or override existing data.
  *
  *  @tparam   R the record type defined per implementation
  */
 @throws(classOf[HectorException])
 @throws(classOf[ValidationException])
 def write(record: R, deleteFirst: Boolean) {
  validate(record)
  if (deleteFirst) remove(record)
  val thriftTemplate = this.getThriftTemplate
  val (k, c) = marshal(record)
  val updater = thriftTemplate.createUpdater(k)
  c.iterator.foreach {
   case (n, v) =>
    updater.setColumn(hcolumn(n, v))
  }
  thriftTemplate.update(updater)
 }

 /**
  * Update a record by specifying intended column to add/update.
  *
  * Will throw an exception when record with specified key does not exist.
  *
  *  @note  Use with caution, this method allows adding a column not defined in the record type.
  *  @param    key of the record
  *  @param    colName the column name
  *  @param    value the column value
  *  @tparam   K the key type defined per implementation
  *  @tparam   V the value type
  */
 @throws(classOf[HectorException])
 @throws(classOf[ValidationException])
 def update[V](key: K, colName: N, value: V) {
  val thriftTemplate = this.getThriftTemplate

  if (false == thriftTemplate.isColumnsExist(key)) {
   throw new NoExistingRowException(key, "update")
  }
  val updater = thriftTemplate.createUpdater(key)

  val column = HFactory.createColumn(colName, value, getKeyspace.createClock)
  updater.setColumn(column)
  thriftTemplate.update(updater)
 }

 /**
  * Update a record by specifying multiple intended columns to add/update.
  *
  * Will throw an exception when record with specified key does not exist.
  *
  *  @note  Use with caution, this method allows adding columns not defined in the record type/column family metadata.
  *  @param    key of the record
  *  @param    map of column name/column value
  *  @tparam   K the key type defined per implementation
  */
 @throws(classOf[HectorException])
 @throws(classOf[ValidationException])
 def update(key: K, map: Map[N, Any]) {
  val thriftTemplate = this.getThriftTemplate

  if (false == thriftTemplate.isColumnsExist(key)) {
   throw new NoExistingRowException(key, "update")
  }

  val updater = {
   thriftTemplate.createUpdater(key)
  }
  map.iterator.foreach {
   case (n, v) =>
    val column = HFactory.createColumn(n, v, getKeyspace.createClock)
    updater.setColumn(column)
  }
  thriftTemplate.update(updater)
 }

 /**
  * Add multiple records, or override when such with the same key exists.
  *
  * Will throw an exception when record with specified key does not exist, automatically cancelling whole operation.
  *
  *  @note  Use with caution, this method allows adding columns not defined in the record type/column family metadata.
  *  @param    key of the record
  *  @param    map of column name/column value
  *  @tparam   K the key type defined per implementation
  */
 @throws(classOf[HectorException])
 @throws(classOf[ValidationException])
 def writeBatch(records: List[R], deleteFirst: Boolean) {
  val cf = this.getThriftTemplate.getColumnFamily
  val thriftTemplate = this.getThriftTemplate

  records.iterator.foreach { it => validate(it) }

  val mutator = thriftTemplate.createMutator

  records.iterator.foreach { it =>
   if (deleteFirst) remove(it)
   marshal(it) match {
    case (k, c) => c.iterator.foreach { tuple =>
     mutator.addInsertion(k, cf, HFactory.createColumn(tuple._1, tuple._2, getKeyspace.createClock))
    }
   }
  }
  thriftTemplate.executeBatch(mutator)
 }

 /**
  * Read record by key, returning Option
  *
  *  @param    key of the record
  *  @tparam   K the key type defined per implementation
  *  @tparam   R the record type defined per implementation
  */
 @throws(classOf[HectorException])
 def read(key: K): Option[R] = {
  val thriftTemplate = this.getThriftTemplate
  val result = thriftTemplate.queryColumns(key)
  unmarshal(result)
 }

 /**
  * Remove entire row by key
  *
  *  @param    key of the record
  *  @tparam   K the key type defined per implementation
  */
 @throws(classOf[HectorException])
 def remove(key: K) {
  this.getThriftTemplate().deleteRow(key)
 }

 /**
  * Remove entire row using the record's id
  *
  *  @tparam   R the record type defined per impl
  *  ementation
  */
 @throws(classOf[HectorException])
 def remove(record: R) {
  remove(getKey(record))
 }

 /**
  * Get key field option (thru reflection)
  */
 protected def getKeyFieldOpt[E <: R: Manifest] = implicitly[Manifest[E]].erasure.getDeclaredFields.find(_.getType.equals(classOf[Id[K]]))
 
 /**
  * Get N serializer (thru reflection)
  */
 protected def getNSerializer[E <: N: Manifest]():Serializer[N] = SerializerTypeInferer.getSerializer[N](implicitly[Manifest[E]].erasure)

 /**
  * Get key for record (thru reflection)
  */
 def getKey[E <: R: Manifest](record: R): K = {
  try { getKeyField.get(record).asInstanceOf[Id[K]]}
  catch {
   case e =>
    throw new WrongModelException(implicitly[Manifest[E]].erasure, "Key type specified in template does not match actual key type of record.", e)
  }
 }

 /**
  * Validate record using JSR-303
  *
  *  @param    record
  *  @tparam   R the record type defined per implementation
  */
 @throws(classOf[ValidationException])
 def validate(record: R) {
  val violations = validator.validate(record)

  if (false == violations.isEmpty()) {
   val exceptionMessage = violations.iterator
    .map(it => it.getPropertyPath.toString + " " + it.getMessage)
    .mkString(", ")

   throw new ConstraintViolationException(exceptionMessage, violations.asInstanceOf[java.util.Set[ConstraintViolation[_]]])
  }
 }
 /* CONCRETE METHODS [END] */

 /* ABSTRACT METHODS [BEGIN] */
 /**
  * Transform record into tuples with format (key, List[(columnName, columnValue)])
  */
 def marshal(record: R): (K, List[(N, Any)])

 /**
  * Transform ColumnFamilyResult into record
  */
 def unmarshal(columns: ColumnFamilyResult[K, N]): Option[R]

 /**
  * Get underlying Thrift template used by this spec template
  */
 def getThriftTemplate(): ColumnFamilyTemplate[K, N]
 
 /**
  * Get column name serializer used by this spec template
  * This became mandatory for creating composite columns using the Hector client.
  */
 def getNameSerializer():Serializer[N]

 def getKeyField: Field

 def getKeyspace: Keyspace
 /* ABSTRACT METHODS [END] */
}

And a sample implementation:
PS: Don't mind the CDI annotations. And the transient annotations are there just so it plays along well with CDI.

@Named( "ItemRepository" )
@ApplicationScoped
class ItemCFAdapter extends CommonStandardCFAdapter[Item, UUID, String] with Serializable {
 @transient val keyField = {
  getKeyFieldOpt[Item] match {
   case Some( field ) =>
    field.setAccessible( true )
    field
   case None =>
    throw new WrongModelException( classOf[Item], "Cannot find field with Id metadata." )
  }
 }

 @transient val nameSerializer = getNSerializer[String]

 @Inject
 @transient
 var keyspace: Keyspace = _

 var thriftTemplate: ThriftColumnFamilyTemplate[UUID, String] = _

 @PostConstruct
 def initialise() {
  thriftTemplate = new ThriftColumnFamilyTemplate( keyspace, CF.CF_NAME, us, as )
 }

 override def marshal( record: Item ): ( UUID, List[( String, Any )] ) = {
  ( getKey( record ), List(
   ( "label", record.label ),
   ( "url", record.url ) ) )
 }

 override def unmarshal( columns: ColumnFamilyResult[UUID, String] ): Option[Item] = {
  val l = columns.getString( "label" )
  val u = columns.getString( "url" )
  ( Option( l ), Option( u ) ) match {
   case ( Some( _ ), Some( _ ) ) =>
    Option( new Item {
     id = columns.getKey
     label = l
     url = u    } )
   case _ =>
    None
  }
 }

 override def getThriftTemplate() = thriftTemplate

 override def getKeyField() = keyField

 override def getNameSerializer() = nameSerializer

 override def getKeyspace() = keyspace

}

Back to JSP

Alright, so JSP is old and perhaps no longer endorsed by Oracle (there's no section on JSP in the Java EE 6 tutorial).  But it, I find, remains a sane, mature, and better-supported choice of technology for generating web content.  Many other templating engines suffer from lack of support and continued development (due to less usage), crippled integration with other technologies (i.e. frameworks), or unsatisfactory tooling.

Most of the hate-bordering rants on JSP that I see have nothing to do with the JSP technology itself.  The problems they face arise from anti-patterns: spaghetti code, lack of separation of concern, or simply outdated version of JSP spec.

What would be cool for the next JSP spec update is a way to supply partial XML directly from the controller, like that in Lift web framework.  With CDI, yeah.  Something like:

@Produces
@XmlNode
@Named("calendar")
def getCalendar:XmlNode = {
  return 
Calendar
Monday to Sunday
}

JAX-RS ftw

I never realised this before, partly because the Java EE 6 documentation doesn't make it obvious, but apparently one can use the JAX-RS to create web page controllers.  It seems to be implementation specific, however.  JBoss Resteasy, with Seam Resteasy, has built-in support for freemarker and Velocity templates as well as undocumented for JSP.  Jersey, on the other hand, afaik, only does for JSP.  It's pretty snazzy considering the features JAX-RS has and its deep integration with the Java EE stack--all those REST methods, CDI scopes, streamlined authentication and authorization, etc.
Bottom line, Java EE 6 hasn't abandoned stateless web!  Or something like that.

My Little Take on Backend Development

Update 29-10-2012:
I found this blog post more comprehensively in defense of Java EE 6.
Original post:
This comes from someone who only just recently read about JTA and JTS. Take this with a grain of salt, so to speak.

I have some experience using the Spring Framework, mainly the Spring MVC sometime about 2years ago, and some again just recently (as indicated in my previous post).  Back then, it was first a multifinancing application, second a message broadcasting engine, sort of.  Neither of which I created from the ground up.  I was merely adding features and so on.  I couldn't compare it against the Java EE 6 at that time, lack of understanding of their internals and so on.

The message broadcasting engine had to be improved so that it could support more load.  There were topics such as clustering, high availability, parallelism, concurrency, etc.  I think it was then that I came across the JMS and some asynchronous processing features provided by the EJB 3.  That was to be my gateway to Java EE 6.   Afterwards it was a haphazard series of choice to learn the actor model, CSP, Scala, Erlang, Haskell, NoSQL, etc.

So I wonder what was it again, Spring Framework's winning points.  Their documentation is among the best.  Their framework itself is rock solid, for what it is.  What it is, really, is a little confusing, though.  It appears to be sort of an alternative to the Java EE stack, but heavily relies on it.  It manages the object lifecycles.  Java EE does that as well, manage object lifecycles.  Two things manage your object lifecycles.  Obviously you can run Spring Framework on a standard servlet container, but I see everywhere that it is recommended that you use, say, the JTA provided by the container when available.  It would be unavoidable that both containers will manage the object lifecycles if you used CMT alongside Spring.  And how is it that one could share a bean across deployments in Spring?  Even if you could, I think using Spring remoting, your object lifecycles management would be more complicated because it would be a communication between two unrelated containers.  It looks to me that the EJB specification is superior in this regard, with its local and remote beans concept and tighter integration with JTA and the rest of the Java EE specification.

Anyway, honestly I'm not a big fan of dependency injection, Spring or CDI.  It's a little too much magic for me.  Language level singleton object construction available in Scala and programmatic lookup and vending are easier to work with.