 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Tom
Guest
|
 Posted: Wed Nov 26, 2003 7:46 pm Post subject: orphan objects |
 |
|
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?
|
|
| Back to top |
|
 |
Eric Sosman
Guest
|
| Posted: Wed Nov 26, 2003 8:07 pm Post subject: Re: orphan objects |
|
|
Tom wrote:
| Quote: |
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?
|
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?
--
[email]Eric.Sosman (AT) sun (DOT) com[/email]
|
|
| Back to top |
|
|
Christophe Vanfleteren
Guest
|
| Posted: Wed Nov 26, 2003 8:15 pm Post subject: Re: orphan objects |
|
|
Tom wrote:
| Quote: | 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.
|
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.
--
Regards,
Christophe Vanfleteren
|
|
| Back to top |
|
|
Chris Smith
Guest
|
| Posted: Wed Nov 26, 2003 8:51 pm Post subject: Re: orphan objects |
|
|
Tom wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
|
|
| Back to top |
|
|
Tom
Guest
|
| Posted: Thu Nov 27, 2003 2:47 am Post subject: Re: orphan objects |
|
|
Chris Smith <cdsmith (AT) twu (DOT) net> wrote
| Quote: | Tom wrote:
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.
|
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
|
|
| Back to top |
|
|
Chris Smith
Guest
|
| Posted: Thu Nov 27, 2003 3:23 am Post subject: Re: orphan objects |
|
|
Tom wrote:
| Quote: | 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"! 
|
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.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
|
|
| Back to top |
|
|
Tom
Guest
|
| Posted: Sat Nov 29, 2003 11:48 pm Post subject: Re: orphan objects |
|
|
Chris Smith <cdsmith (AT) twu (DOT) net> wrote
<snip>
| Quote: | 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.
| Quote: | 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.
|
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.
| Quote: | 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
|
|
| Back to top |
|
|
Chris Smith
Guest
|
| Posted: Sun Nov 30, 2003 5:10 am Post subject: Re: orphan objects |
|
|
Tom wrote:
| Quote: | Chris Smith <cdsmith (AT) twu (DOT) net> wrote...
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.
|
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.
| Quote: | 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.
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.
|
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.
| Quote: | 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?
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
|
|
| Back to top |
|
|
Fu, Ren-Li
Guest
|
| Posted: Sun Nov 30, 2003 8:52 am Post subject: Re: orphan objects |
|
|
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
|
|
| Back to top |
|
|
Tom
Guest
|
| Posted: Sun Nov 30, 2003 9:18 pm Post subject: Re: orphan objects |
|
|
"Fu, Ren-Li" <frl8 (AT) rogers (DOT) com> wrote
| Quote: | 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?
|
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! ;-)
| Quote: | Those questions should help you find an answer if my two solutions didn't
work.
-frl
|
Thanks for your help!
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
