Skip navigation
This poll was archived on Dec 21, 2009.

Should support for custom objects in Fqns be dropped?

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.
Poll Results
  • Yes - I never use them and don't want to deal with the performance hit (91%)
  • No - my application depends on being able to use custom Fqn elements (9%)


Delete Poll

Confirm delete of Should support for custom objects in Fqns be dropped?

Warning: This will delete the poll and all of its comments.