I see your point, Brian. The GUID approach really would be just a fudge. My main purpose in restricting Fqns is performance, so let's see if this can be achieved in other ways. But first, addressing Jason's suggestions: "jason.greene(a)jboss.com" wrote : 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. Agreed. We would just be pushing the problem into the user space. "jason.greene(a)jboss.com" wrote : | 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=4136088#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...