This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Beanification

Posted by Chris Dailey on January 04, 20100 at 2:04 PM

> > Some objects
> > are holders for algorithms (say, the Math object in java.lang),
> java.lang.Math is a class, but there is little reason to call
> it an "object". While you could create an instance of it, it
> has no non-final fields and no nonstatic methods.
[...]
> Certainly this is a class that shouldn't be a Bean.

Agreed, Math is not intended to be instantiated, so it makes no sense to talk about it in terms of being a bean.

As a side note, java.lang.Math is final; it may also have a private 0-arg constructor, which would make it uninstantiatable (if that's a word), if the designer deemed that would be a misuse.

> > and some objects have no concept on what it means to be saved
> > (say, for instance, a Transaction object which may have run-time
> > sense, but not necessarily persistant sense).

> Actually, I think there's a good argument for making your "Transaction"
> object Serializable, at least client-side. The type of object you're
> describing is called, in Enterprise JavaBeans, a "Session" bean.
[...]

But you might want to avoid having an open database transaction for days (weeks or months!), and thus may decide that having a Transaction be Serializable while open is an unsafe thing to do.

Also, does it make sense for an InputStream (or OutputStream) to be Serializable? (java.io.InputStream is not Serializable, but you could presumably make a class that is Serializable.) And if it doesn't make sense, given the agreement about not making a bean Serializable that has e.g. an Image member, then classes with InputStreams would probably also not be valid/good beans.

My first thought is that Serialization should be valid for the long haul ... serialized data should be transportable through time and space (excepting class version changes too great for deserialization to handle, but that's another topic). Pass around a URL, not the return value of URL.openStream(). This is relatively equivalent to the "handle" concept you mentioned (and I snipped, oops).

It appears that some objects have a requirement of a limited life time or are only valid in a specialized context (such as InputStream and Transaction), and these would not be good candidates for Serialization.

Cheers,
Chris Dailey