Originally posted by Chris Mathews:
Sure, but since JNDI can be clustered and accessed remotely... it is foolish to bind objects that are not Serializable.
There are many reasons to bind non-serializable objects.
1) Even within clusters, non-serializable objects can still be bound to to the context, whether locally or globally (ie. copies of the object can be replicated across the cluster.) In any case, a service provider is free to provide an implementation to bind non-serializable objects within a remote, clustered environment.
2) Serializable is a
Java concept, but naming and directory services go beyond Java. Contents within a particular naming service might have been populated by a C, Perl, or even Visual Basic code with no concept of Serializable (or even of objects.) To require Serializable would prevent JNDI from working with non-Java services.
3) There's an implication that objects in the server are stored in their Serializable forms. However, it's common to store a reference to the object instead. For example, instead of binding an image, one can bind the image's url (which might be a simple ASCII
string.) For Java objects, JNDI supports this approach through the Referenceable interface. A Referenceable object may be bound even if it is non-serializable.
4) There is no guarantee that even Serializable objects can be bound... a JNDI service provider is free to refuse them. Providers may also create "read-only" JNDI services, not supporting binding of any type at all.
5) When working with LDAP, it is common to bind non-serializable DirContext objects, for interoperability with non-Java LDAP servers. Not all providers support binding DirContext objects, but most do.
6) Also, JNDI provides the StateFactory interface to bind arbitrary types. Using this interface one can write custom code to convert any object into a form suitable to the JNDI service provider.
Anyway, to answer the original question, the JNDI specification does not restrict the type of objects which can be bound, instead providing a variety of mechanisms to work with non-serializable objects. These mechanisms are necessary to preserve interoperability with non-Java services and to allow provider-specific enhancements.
-Ade Barkah