Stupid Newbie Question: get name of instantiated variable?

[Ed Dana]

That's right. How do I get the name of a variable that has been
instantiaded from a class? I don't want the class name, I want the
variable name.

If I instantiate: String Fred = new String( "Flintstone"), how do I
extract the variable name "Fred?"

Thanks in advance,
Ed.

 

[Bob]

That's right. How do I get the name of a variable that has been
instantiaded from a class? I don't want the class name, I want the
variable name.

If I instantiate: String Fred = new String( "Flintstone"), how do I
extract the variable name "Fred?"

As far as I know, that's not possible.

A variable is just a bitbox that holds a set of binary digits. Those
digits may refer to a location where an object can be found, or they
might represent an integer or floating-point value.

One object may have dozens of reference variables 'pointing' to it. So
getting a variable name isn't possible. Not to mention, the variable
would be out of scope, so you would not be permitted to use it.

Perhaps you can tell us why you were hoping to get the variable name?
What would you like to be able to do with it?

 

[Thufir]

"Java reflection is useful because it supports dynamic retrieval of
information about classes and data structures by name..."

from
<http://java.sun.com/developer/technicalArticles/ALT/Reflection/index.html#7>

That sounds like retrieving the (reference) name for a field is
possible...?

 

[Andrew McDonagh]

"Java reflection is useful because it supports dynamic retrieval of
information about classes and data structures by name..."

from
<http://java.sun.com/developer/technicalArticles/ALT/Reflection/index.html#7>

That sounds like retrieving the (reference) name for a field is
possible...?

Its possible, much like shooting ones self in the head is possible. The
question should really be 'why would you want it?'

The only valid use of this part of the reflection api I've come across,
is inside an OO persistence library.

 

[Guest]

"Java reflection is useful because it supports dynamic retrieval of
information about classes and data structures by name..."

from
<http://java.sun.com/developer/technicalArticles/ALT/Reflection/index.html#7>

That sounds like retrieving the (reference) name for a field is
possible...?

Using reflection, you must either cycle through ALL fields or already know
the name of the field you want. IOW, useless in the situation given by
the OP.

La'ie Techie
: I haven't lost my mind; I have it backed up on disk ... somewhere.

 

[Tor Iver Wilhelmsen]

That sounds like retrieving the (reference) name for a field is
possible...?

Yes, a field name in a class - but you need the class name for that,
and the OP did not want that. Given an object (as per the OP) you
cannot get the name of a variable pointing to that object. Plus, names
for method-local variables do not need to exist in the class file
since they are turned into stack offsets by the compiler.

Also:

String foo = "Goo";
String fie = foo;

Both "foo" and "fie" now points at the same object - which name should
have been reported had it been possible to ask for variable names?

 

[Thufir]

Yes, a field name in a class - but you need the class name for that,
and the OP did not want that. Given an object (as per the OP) you
cannot get the name of a variable pointing to that object.

Can't the constructor be retrieved to find the class name?

Plus, names
for method-local variables do not need to exist in the class file
since they are turned into stack offsets by the compiler.

Then only static or member fields are retrieved from reflection, if I
follow.

Also:

String foo = "Goo";
String fie = foo;

Both "foo" and "fie" now points at the same object - which name should
have been reported had it been possible to ask for variable names?

whichever comes "first," since they both point to the same object

Seriously, though, I don't know. If foo and fie are static, or member,
fields of their respective class(es), then their names and types (?)
are retrievable. As another said, all String references *could* be
cycled through. Could foo and fie be found and determined to point to
the object in question under those conditions? Pardon my tortured
grammar!

 

[Ed Dana]

Its possible, much like shooting ones self in the head is possible. The
question should really be 'why would you want it?'

Because, as programmers, we're in the business of information
processing, and this is a bit of information that can be processed.

I merely want the name of the instantiated object so I can use it as a
bit of data. If I create a "Steering" class, and then instantiate it as
HandleBar, I want to be to display that it is a "HandleBar."

Ed.

 

[Thufir]

Yes, a field name in a class - but you need the class name for that,
and the OP did not want that. Given an object (as per the OP) you
cannot get the name of a variable pointing to that object.

Can't the constructor be retrieved to find the class name?

Plus, names
for method-local variables do not need to exist in the class file
since they are turned into stack offsets by the compiler.

Then only static or member fields are retrieved from reflection, if I
follow.

Also:

String foo = "Goo";
String fie = foo;

Both "foo" and "fie" now points at the same object - which name should
have been reported had it been possible to ask for variable names?

whichever comes "first," since they both point to the same object

Seriously, though, I don't know. If foo and fie are static, or member,
fields of their respective class(es), then their names and types (?)
are retrievable. As another said, all String references *could* be
cycled through. Could foo and fie be found and determined to point to
the object in question under those conditions? Pardon my tortured
grammar!

 

[Steve Horsley]

Because, as programmers, we're in the business of information
processing, and this is a bit of information that can be processed.

I merely want the name of the instantiated object so I can use it as a
bit of data. If I create a "Steering" class, and then instantiate it as
HandleBar, I want to be to display that it is a "HandleBar."

Ed.

And what name would you like to find the Widget has after this bit of code:

Widget w = new Widget();
Widget x = w;
Objecy y = x;
w = null;
// I suppose its name at the moment is "x and y".

Or this bit of code:

Widget[] widgets = new Widget[5];
Widgets[0] = new Widget();
// now it doesn't have a name at all.

Perhaps you are looking for something like a java.util.Map, where you can
store a lookup map of Object->Object. Using Strings for the key is common.

Steve

 

[Tor Iver Wilhelmsen]

Can't the constructor be retrieved to find the class name?

You can ask any object for its Class, and ask that for the name. But
the OP did not want that, but the name of a variable pointing to the
object. And objects do not have any knowledge of pointers to them.

Then only static or member fields are retrieved from reflection, if
I follow.

Yes.

 

[Thufir]

You can ask any object for its Class, and ask that for the name. But
the OP did not want that, but the name of a variable pointing to the
object. And objects do not have any knowledge of pointers to them.

[..]

Could each of those classes available fields be compared, somehow, to
determine if they point to the object in question? This is getting
very hypothetical

 

[Richard Chrenko]

Because, as programmers, we're in the business of information
processing, and this is a bit of information that can be processed.

I merely want the name of the instantiated object so I can use it as a
bit of data. If I create a "Steering" class, and then instantiate it as
HandleBar, I want to be to display that it is a "HandleBar."

Ed.

Perhaps I don't understand your problem correctly, but it appears as
though you are taking an odd approach. The accepted solution is for the
class to define a 'name' attribute which is accessible using set() and
get() methods:

Thingie thingie1 = new Thingie("the first thingie"); // constructor
assigns the given String to the 'name' attribute of class Thingie
Thingie thingie2 = new Thingie("the second thingie");
println("The name of the first object is ", thingie1.getName());
println("The name of the second object is ", thingie2.getName());

 

[Ed Dana]

Perhaps I don't understand your problem correctly, but it appears as
though you are taking an odd approach. The accepted solution is for the
class to define a 'name' attribute which is accessible using set() and
get() methods:

Thingie thingie1 = new Thingie("the first thingie"); // constructor
assigns the given String to the 'name' attribute of class Thingie
Thingie thingie2 = new Thingie("the second thingie");
println("The name of the first object is ", thingie1.getName());
println("The name of the second object is ", thingie2.getName());

Which is the more risk free approach?

Let's say there's a method that does what gets the name directly from
the environment, like I want, we'll call it getVariableName();

Thingie fred = new Thingie( "fred" );
Thingie larry = new Thingie( "larry" );

fred = larry

println( fred.getName( ) );
println( getVariableName( fred ) );

So, in theory, which would most reliably return the information I wanted?

I considered the approach you suggested, I was just trying to find out
if there was a more dependable way to do it.

Ed.

 

[Ed Dana]

And what name would you like to find the Widget has after this bit of code:

Widget w = new Widget();
Widget x = w;
Objecy y = x;
w = null;
// I suppose its name at the moment is "x and y".

Or this bit of code:

Widget[] widgets = new Widget[5];
Widgets[0] = new Widget();
// now it doesn't have a name at all.

Perhaps you are looking for something like a java.util.Map, where you
can store a lookup map of Object->Object. Using Strings for the key is
common.

Everything has a name. That's how you reference it in code, so, the name
of your Widget is "widgets," and the name of the first widget is
"widgets[0]."

And these names are just aliases for the address space they point to.

Ed.

 

[Steve Horsley]

And what name would you like to find the Widget has after this bit of
code:

Widget w = new Widget();
Widget x = w;
Objecy y = x;
w = null;
// I suppose its name at the moment is "x and y".

Or this bit of code:

Widget[] widgets = new Widget[5];
Widgets[0] = new Widget();
// now it doesn't have a name at all.

Perhaps you are looking for something like a java.util.Map, where you
can store a lookup map of Object->Object. Using Strings for the key is
common.

Everything has a name. That's how you reference it in code, so, the name
of your Widget is "widgets," and the name of the first widget is
"widgets[0]."

And these names are just aliases for the address space they point to.

Ed.

How about this:

List l = new LinkedList();
l.add(new HashMap()); // and the name of the HashMap is???
((HashMap) l.get(0)).put("Gizmo", new Widget());

So now what's the name of the Widget instance?
I really don't think it makes sense to ask what the "name" of the
object is. That name will vary vrom object to object. It's immediate
name (as known by the HashMap code) cannot be known without examining
the source code for a HashMap, and may vary depending on the VM
library version / maker being used at the time.

Different pieces of code (even within the same class) have different
names for objects. A chain of objects pointing to other objects pointing
to other objects will have a chain of names, possibly involving index
numbers. Many such chains may end up pointing at the same object.
It really makes no sense to think that an object has "a name".

Steve

 

[Ed Dana]

How about this:

List l = new LinkedList();
l.add(new HashMap()); // and the name of the HashMap is???
((HashMap) l.get(0)).put("Gizmo", new Widget());

Now you're just making it complicated.

So now what's the name of the Widget instance?
I really don't think it makes sense to ask what the "name" of the
object is. That name will vary vrom object to object. It's immediate
name (as known by the HashMap code) cannot be known without examining
the source code for a HashMap, and may vary depending on the VM
library version / maker being used at the time.
Different pieces of code (even within the same class) have different
names for objects. A chain of objects pointing to other objects pointing
to other objects will have a chain of names, possibly involving index
numbers. Many such chains may end up pointing at the same object. It
really makes no sense to think that an object has "a name".

Listen, Steve?

Debuggers do it all the time. They display both the _variable name_ AND
its value. All I'm asking is if there is similar functionality available
programmatically. Granted, they have access to the source code, but the
fact remains: they do it. And, for the purpose of my question, I'm not
interested in interrogating anonymous objects, only named ones. I simply
want to print it out as a bit of information, like a debugger does.

This is not serious functionality. It's just a curious question. And I'm
merely asking if it can be done easily.

Ed.

 

[Tor Iver Wilhelmsen]

Debuggers do it all the time. They display both the _variable name_
AND its value. All I'm asking is if there is similar functionality
available programmatically.

The debugger is an EXTERNAL process that is inspecting the runtime.
And it sees the variables first, THEN the object they point to. The
relationship does NOT go the other way.

Granted, they have access to the source code,

No, they do not necessarily have that. Debuggers use "debug info" the
compiler puts into the class file.

but the fact remains: they do it.

Yes. In ways that are NOT available to the running Java process.

Provided the class file And, for the purpose of my question, I'm not
interested in interrogating anonymous objects, only named ones.

And we are trying to tell you there is NO such thing as "named
object". Objects are completely independent of any variables that may
or may not point to them.

I simply want to print it out as a bit of information, like a
debugger does.

Then USE a debugger.

This is not serious functionality. It's just a curious question. And
I'm merely asking if it can be done easily.

It cannot.

 

[Ed Dana]

Then USE a debugger.




It cannot.

That's a bit absolute, ain't it?

What you are telling me, if I interpret it correctly, is there is no way
do it _natively,_ without the inclusion of a debugger package like the JDI.

Ed.

 

[Thufir]

In all fairness, your question was "can it be done EASILY", not "can it
be done".