I asked a similar question prior to releasing 2.0.0, and I'd like to ask again to gauge the value of supporting Fqns that can take any object as an element. Supporting custom objects add a lot of complexity when it comes to replication and cache loading since Fqns need to be serialized and in these cases, the right class loader with knowledge of user classes needs to be used to deserialize the Fqns and this can be both tricky and expensive (the current workarounds in 2.x are costly and impact serialization performance). Prior to releasing 2.x I asked whether Fqns should only comprise of Strings.  The answer was a clear "no", so this time around I'm asking whether Fqns should only be allowed to contain Strings and Java primitives (boolean, char, byte, short, int, long, float, double).  Combinations would be allowed (e.g., /"hello"/false/9.0f.