orphan objects

Thread view:

Tom - 26 Nov 2003 19:46 GMT

Suppose that you have code along the lines of what is shown below:

SomeObject x = new SomeObject();
SomeCollection coll = new SomeCollection(); //might be a Vector,
ArrayList, etc.
coll.add(x);
x = new SomeObject(); //occurs AFTER x is added to the collection

At this point, the object that was added to the collection is what I
mean by an orphan object. The reference 'x' no longer points to it,
but it isn't garbage either. It lives on as an anonymous object in
the Collection.

Obviously, coll.remove(x); won't work any more since x no longer
points to the original object.

Is there any way to identify which element is an orphan so it could be
removed from the Collection?

Reply to this Message

Eric Sosman - 26 Nov 2003 20:07 GMT

> Suppose that you have code along the lines of what is shown below:
>
[quoted text clipped - 14 lines]
> Is there any way to identify which element is an orphan so it could be
> removed from the Collection?

The original SomeObject is not an "orphan," because
the Collection holds a reference to it. The fact that
this reference is part of the Collection object and not
a named variable makes no difference: all references are
created equal. (Well, not "all" -- but the special-purpose
classes in java.lang.ref are a topic for another day.)

You can easily iterate over all the objects in the
Collection and test whether each of them happens not to be
referred to by references x,y,z, and remove those objects
if you please -- but I confess I see little point in the
exercise. What are you trying to accomplish?

Signature

Eric.Sosman@sun.com

Reply to this Message

Christophe Vanfleteren - 26 Nov 2003 20:15 GMT

> Suppose that you have code along the lines of what is shown below:
>
[quoted text clipped - 11 lines]
> Obviously, coll.remove(x); won't work any more since x no longer
> points to the original object.

Not if you implement equals correctly. It's in the api docs. Most collections
use .equals() to compare the items. There are collections out there that use
identity though.

Signature

Regards,
Christophe Vanfleteren

Reply to this Message

Chris Smith - 26 Nov 2003 20:51 GMT

> At this point, the object that was added to the collection is what I
> mean by an orphan object. The reference 'x' no longer points to it,
> but it isn't garbage either. It lives on as an anonymous object in
> the Collection.

Okay. I think that's a strange definition of "orphan", but you seem to
understand what's going on and the word doesn't really have a technical
definition in this context, so I'll go with it. I'm a bit concerned
that you're implying that all objects must be specifically referred to
by some in-scope variable name at all times in order to be useful... and
that couldn't be further from the truth.

> Obviously, coll.remove(x); won't work any more since x no longer
> points to the original object.

Right. That's assuming that the new object referred to by x doesn't
actually report itself as being equal to the original... which it won't
unless you've overridden equals to ensure that it does.

> Is there any way to identify which element is an orphan so it could be
> removed from the Collection?

No, there's no way to identify objects that are not directly referred to
by variables in scope. If you have a specific set of variables you care
about, then as Eric pointed out it's possible to walk through the list
and identify those elements that are not pointed to by the specific
variables you want to test. But in general, if you know that you'll
want to remove a specific object from a list at some point in the
future, then you need to save a reference to that object, so that you
can find and remove it when the time comes.

Signature

www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Tom - 27 Nov 2003 02:47 GMT

> > At this point, the object that was added to the collection is what I
> > mean by an orphan object. The reference 'x' no longer points to it,
[quoted text clipped - 26 lines]
> future, then you need to save a reference to that object, so that you
> can find and remove it when the time comes.

I suspected as much. Basically, I end up in the same situation that I
would if I had added an anonymous instantiation to the Collection.

It's the same library that I have been creating that I referenced in
the other post that you answered for me. Students will create objects
that appear on the screen and can be manipulated through method calls.
I keep an ArrayList behind the scenes to repaint them properly.

If the student re-instantiates an object, I have no way to identify
which one to remove from my list so I end up with a "dead" object on
the screen that can no longer be manipulated. I guess that will
become a "feature"! ;-)

Thanks again.

Tom

Reply to this Message

Chris Smith - 27 Nov 2003 03:23 GMT

> It's the same library that I have been creating that I referenced in
> the other post that you answered for me. Students will create objects
[quoted text clipped - 5 lines]
> the screen that can no longer be manipulated. I guess that will
> become a "feature"! ;-)

Well, that's actually a different question from the one you originally
asked, and it has a slightly more positive answer. If you just want
methods that are not reachable at all except through your list (which is
quite different from wanting objects that aren't referenced by named
variables in the root set), then java.lang.ref.WeakReference might be
able to help.

There are still some limitations: you can't ask for the full set of
otherwise unreferenced object at just any point; you have to wait for
the garbage collector to identify them. Once the garbage collector
*does* identify them, though, it will collect them and you can remove
the WeakReference from your list. If you're trying for a performance
safeguard against dead objects, that may be good enough. I'd suggest
you check out the API docs for WeakReference, and perhaps also
ReferenceQueue, in the java.lang.ref package.

On a parallel note, though, it's always best to at least plan for the
possibility that people will use your API safely; so please consider
providing a way for the student to remove an object that they *know* is
no longer used, rather than waiting for the garbage collector to find
and remove it. Perhaps you can teach some concepts about resource
management at the same time.

Signature

www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Tom - 29 Nov 2003 23:48 GMT

<snip>

> Well, that's actually a different question from the one you originally
> asked, and it has a slightly more positive answer. If you just want
> methods that are not reachable at all except through your list (which is
> quite different from wanting objects that aren't referenced by named
> variables in the root set), then java.lang.ref.WeakReference might be
> able to help.

Can you elaborate? I don't understand the difference.

> There are still some limitations: you can't ask for the full set of
> otherwise unreferenced object at just any point; you have to wait for
[quoted text clipped - 4 lines]
> you check out the API docs for WeakReference, and perhaps also
> ReferenceQueue, in the java.lang.ref package.

Thanks again for the help. No, I'm not worried about performance
issues. Just explaining why the blue object can no longer be
controlled but is still on the screen, etc.. Actually, this may be a
good thing as it can lead into a discussion of reassignment, the
garbage collector, and objects in general.

> On a parallel note, though, it's always best to at least plan for the
> possibility that people will use your API safely; so please consider
> providing a way for the student to remove an object that they *know* is
> no longer used, rather than waiting for the garbage collector to find
> and remove it. Perhaps you can teach some concepts about resource
> management at the same time.

I'd planned on using my library to primarily teach the basics: if's,
loops, subclassing, overloading, overriding of methods etc.. But
throwing in some fundamentals of resource management can't hurt
either.

I'll have to look through the WeakReference API. None of their
programs will probably run long enough for the gc to run, but if one
did, having the "orphan" object eventually disappear might help the
kids understand the idea of the gc running in the background.

Thanks again for your help.

tom

Reply to this Message

Chris Smith - 30 Nov 2003 05:10 GMT

> Chris Smith <cdsmith@twu.net> wrote...
> <snip>
[quoted text clipped - 6 lines]
>
> Can you elaborate? I don't understand the difference.

Sure. You were (apparently) asking for objects that aren't referred to
by named variables from some context; I'm talking about objects that are
unreferenced from anywhere that's reachable, however indirectly.

> > There are still some limitations: you can't ask for the full set of
> > otherwise unreferenced object at just any point; you have to wait for
[quoted text clipped - 10 lines]
> good thing as it can lead into a discussion of reassignment, the
> garbage collector, and objects in general.

Oh! If it's a visible effect, then forget WeakReference, and you need
to teach students to clean up after themselves. At least it looks like
it'll be obvious if they don't.

> I'll have to look through the WeakReference API. None of their
> programs will probably run long enough for the gc to run, but if one
> did, having the "orphan" object eventually disappear might help the
> kids understand the idea of the gc running in the background.

Actually, at the level you're working at, please do them a favor and
don't start trying to talk about when objects are claimed by the garbage
collector. As I said a few weeks ago, the *only* sensible model for a
beginning programmer is to count on objects always being there and
pretend they exist until the end of time. Only when specifically
dealing with performance issues should anyone be concerned about when
the garbage collector runs. It doesn't sound like your students are
going to be doing performance optimization, so why confuse them?

Signature

www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Fu, Ren-Li - 30 Nov 2003 08:52 GMT

I'm writing a game where lists of objects are stored and I have this
problem. But I realized it's really just a remnant of my C++ days.

What I originally did was to use a "boolean killme" in every object, and
then use iterators to check this once in a while.

But the problem was it was poor technique.. You see, at the moment you
re-assign x = new SomeObject(), what you REALLY should do is "if
(coll.contains(x)) coll.remove(x)" and then do the assignment. But even this
doesen't make sense.

Questions: Why would the student re-instantiate the object if it's already
in the collection? And, why not remove it first as I suggested?

Those questions should help you find an answer if my two solutions didn't
work.

-frl

Reply to this Message

Tom - 30 Nov 2003 21:18 GMT

> I'm writing a game where lists of objects are stored and I have this
> problem. But I realized it's really just a remnant of my C++ days.
[quoted text clipped - 9 lines]
> Questions: Why would the student re-instantiate the object if it's already
> in the collection? And, why not remove it first as I suggested?

They shouldn't re-instantiate objects, but these are raw beginners,
and young kids to boot. They tend to make a lot of "unexpected"
errors. Re-instantiation will be one of the more unlikely ones, but
they've surprised me before! ;-)

> Those questions should help you find an answer if my two solutions didn't
> work.
>
> -frl

Thanks for your help!

Reply to this Message

orphan objects

Free Magazines