Best Practice question - null or empty object?

Question

Given a collection of objects where each object in the collection is an aggregation, is it better to leave references in the object as null or to instantiate an empty object? Now I'll clarify this a bit more.....
I have an object, MyCollection, that extends Collection and implements Serializable(work requirement). MyCollection is sent as a return from an EJB search method. The search method looks up data in a database and creates MyItem objects for each row in the database. If there are 10 rows, MyCollection would contain 10 MyItem objects (references, of course).
MyItem has three attributes:
public class MyItem implements Serializable {
    String name;
    String description;
    MyItemDetail detail;
}When creating MyItem, let's say that this item didn't have any details so there is no reason to create MyitemDetail. Is it better to leave detail as a null reference or should a MyItemdetail object be created? I know this sounds like a specific app requirement, but I'm looking for a best practice - what most people do in this case. There are reasons for both approaches. Obviously, a bunch of empty objects going over RMI is a strain on resources whereas a bunch of null references is not. But on the receiving end, you have to account for the MyItemDetail reference to be null or not - is this a hassle or not?
I looked for this at [url http://www.javapractices.com]Java Practices but found nothing.

Answer 1

I know this sounds like a specific apprequirement,
, but I'm looking for a best practice - what most
people do in this case. It depends but in general I use null.Stupid.Thanks for that insightful comment.
>
I do a lot of database work though. And for that
null means something specific.Sure, return null if you have a context where null
means something. Like for example that you got no
result at all. But as I said before its's best to
keep the nulls at the perimeter of your design. Don't
let nulls slip through.As I said, I do a lot of database work. And it does mean something specific. Thus (in conclusion) that means that, in "general", I use null most of the time.
Exactly what part of that didn't you follow?
And exactly what sort of value do you use for a Date when it is undefined? What non-null value do you use such that your users do not have to write exactly the same code that they would to check for null anyways?