[jboss-dev-forums] [Design of JBossCache] - Re: Fqns containing just Strings

[jason.greene@jboss.com]

After discussing this with Brian, I agree with his position, that we should not force Fqns to be String only. The primary reason is that an Fqn is the definitive key of a node in the cache .  Further, the node is the definitive notion of an "entity" in a domain model.  While it makes things easier for us to restrict Fqns to strings, all we are really doing is pushing the problem onto users, and all of the possible solutions are not nearly as effective as the solution today.

So I propose we look at this from a different perspective, accept that an Fqn must represent multiple Java types, and solve the remaining issues with that prerequisite in mind.

The key issues are:

  | *  Generic type information is wrong and leads to issues (wrong constructor is sometimes called)
  | 
  | We can solve this problem by just removing the generic info. Generics is just not capable of representing an Fqn, since it has an unbounded number of components that are not guaranteed to represent the same type.
  | 
  | *  Fqn's and Strings are not reflexive (Fqn.fromString(fqn.toString()) is not guaranteed to work)
  | 
  | This issue leads to a lot of confusion and misuse of the API. I believe the solution support reflexiveness by adding a getEncodedString(). This method would produce an encoded string that could be used with Fqn.fromString() to produce an equivalent fqn (Fqn.fromString(fqn.getEncodedString()).equals(fqn)). This, of course, means encoding type information for non-string types, and adding proper escaping. Special light-weight encoding would be used for known types, with encoded java serialization as the fallback. This means component types in an Fqn must all be Serializable.
  | 
  | Fqn.toString() would remain the same (normal Java semmantics), to allow for pretty printing.  
  | 
  | *  Performance in equals()
  | 
  | We can introduce something similar to String.intern() with Fqns. This can be implemented by just having a hash map whose key and value is the single true Fqn instance. Equivalent but non-identical fqns will resolve correctly, due to the collections contract. However, identical fqns will resolve quickly since the object identity test short circuits the full comparison.
  | 
  | *  Marshalling Fqns with user defined types (requires marshaling the region fqn first)
  | 
  | This is solved by just having a clear requirement that regions can only use FQNs that are made up of types in the jboss cache classloader. 
  | 
  | *  Cacheloaders rely on Fqn.toString()
  | 
  | This is solved by fixing the reflexiveness problem. They can use the encoded string instead of the pretty print string.
  | 

So to summarize, I believe these are the changes we should make:

  | *  Remove generics from Fqn API
  | *  Enforce all Fqn components to be Serializable
  | *  Introduce Fqn.getEncodedString
  | *  Update cache loaders to use the encoded string
  | *  Update documentation
  | 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135453#4135453

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135453