Class of an object

[Guadalupe Ortiz]

I want to get exactly what type an Object is (for example, a String), to use the that type for casting the object itself. What I mean is, suppose I ve got an Object O, I dont know what type it is and I need to cast it to its type, if i can get the type/class of object it is I would do something like:
OType myObjectCasted = (Otype)O;
Does anybody can help me with this?
Thank-you very much
Guadalupe

[Henrique Sousa]

Hi Guadalupe,

You may accomplish that using the instanceof operator:

public void myMethod(Object o) {
  MyClass my = null;
  if (o instanceof MyClass) {
    my = (MyClass)o;
    // ...
  }
  else {
    //...
  }
}

[David Harkness]

Originally posted by Guadalupe Ortiz:
I want to get exactly what type an Object is (for example, a String), to use the that type for casting the object itself.

The trick is that you don't know what type it is ahead of time, so instanceof is going to be useless. However, what you're asking to do is fairly meaningless since casting -- while it happens at runtime -- is really a compile-time issue.

Let's take your example. You have an object instance obj of some unknown (to you) type O. Since you don't know what O is, you can't call any methods or fields unique to O. Casting is necessary so you can tell the compiler, "I want to call one of O's methods on the instance 'obj'."

I suspect what you want to do is call a method that is defined for Object and ensure that the implementation from the correct class is called. This is called polymorphism and happens automatically without casting.

For example, Object defines toString(), so you can call toString() on an instance of any class (since they all inherit from Object at the root) without casting. If the particular class overrides toString(), that method will be called instead of the one from Object.

Or perhaps I completely misunderstood your question.
[ August 31, 2004: Message edited by: David Harkness ]

[marc weber]

As pointed out above, you've already got polymorphism working for you, so overridden methods of an upcast object will be invoked based on runtime type. So I'm guessing that you intend to downcast -- perhaps so you can access members of the derived object that aren't in the parent...?

If so, perhaps you're looking for the getClass() method in Object. This returns the runtime type of an Object as a Class object...

public class FindOut{
  public static void main(String[] args){
    Object mysteryObj = new String("abc");
    Class whatIsIt = mysteryObj.getClass();
    System.out.println("And our mystery Object is: " + whatIsIt);
  }
}

[ August 31, 2004: Message edited by: marc weber ]
[ August 31, 2004: Message edited by: marc weber ]

[Guadalupe Ortiz]

What I want to exactly is encrip the object in the next way:

SealedObject so = new SealedObject(obj, ecipher);

I can create a SealedObject from any Object, but it must be casted first, so I should something like:

SealedObject so = new SealedObject((String)obj, ecipher); (if I knew it were a String)

I tried to do:
SealedObject so = new SealedObject((obj.getClass())obj, ecipher);
and
SealedObject so = new SealedObject((obj.getClass().getName())obj, ecipher);

but none of them worked as it displayes it was a wrong way of doing a casting.
Thank-you for your answers and if you have any other idea I would be really grateful,
Guadalupe

[Peter den Haan]

Originally posted by Guadalupe Ortiz:
I can create a SealedObject from any Object, but it must be casted first, so I should something like:

SealedObject so = new SealedObject((String)obj, ecipher); (if I knew it were a String)

Why? Why on earth would you want to insert an unnecessary cast that the compiler is probably going to optimise away anyway?

SealedObject so = new SealedObject((Serializable)obj, ecipher);

- Peter

[marc weber]

Yes, it seems that you're trying to incorporate an unnecessary step.

The arguments to this constructor for SealedObject are a Serializible Object and a Cipher. Any object that implements the Serializible interface can be passed. Whatever reference you put in, the constructor is going to convert to a Serializible Object ("method-call conversion"). So why do you need to downcast an argument to a more specific type (e.g., String) when it's just going to be immediately upcast by the method?

Have you tried passing the object without a cast?
[ September 01, 2004: Message edited by: marc weber ]

[Guadalupe Ortiz]

Yes, I tried it and i get the next error message:
"The constructor SealedObject(Object, Cipher) is undefined"
Only if I do the cast it weorks

[Peter den Haan]

Originally posted by Guadalupe Ortiz:
"The constructor SealedObject(Object, Cipher) is undefined"

Yes, well, that's absolutely correct, isn't it? I don't mean to offend you, but have you carefully read the documentation or any of our responses to your question? If you'd just look in the javadoc for SealedObject, in particular the constructors, or simply use the code I gave you above as given, all shall become clear

- Peter
[ September 01, 2004: Message edited by: Peter den Haan ]

[Guadalupe Ortiz]

You are absolutely right. I am sorry I didnt realize about the Serializable word in your previos message.
Thank-you very much for your help
Guadalupe

[marc weber]

Peter: Is the cast to Serializible needed here, or did you just include that to illustrate a point? My understanding is that if the object implements the interface, then it will be automatically converted by the method; and if it doesn't implement the interface... Well, then I would expect the error that Guadalupe is reporting (or an exception if the Serializible cast is attempted).

[Ernest Friedman-Hill]

The compiler has to know that the variable points to a Serializable for the call to compile. If he has a variable of type Object, then, since Object is not Serializable, the call won't compile without a cast, even if the object being referred to does, in truth, implement Serializable.

It's all about what the compiler knows, not about what the "real" type is.

[marc weber]

Oh, of course... The compiler just sees a simple Object here, so we need to tell it that the Object is, in fact, Serializible. And if we're wrong, we'll get an exception at runtime.

The automatic method-call conversion I described would only work if we had an extended (more specific) type that the compiler would be able to recognize as Serializible. Right?
[ September 01, 2004: Message edited by: marc weber ]

[Ernest Friedman-Hill]

Right.

[David Harkness]

Casting doesn't do anything to the object; nor does passing it to a method that requires one of the object's superclasses or interfaces. Casting only verifies at runtime that the claim you made to the compiler is correct, throwing an exception if not.

[marc weber]

Right, the object itself is not affected by casting or conversion. This is just a programmer's assurance to the compiler.

I read somewhere that it's the reference that's actually being cast or converted, but I'm not convinced this is accurate. The reference is essentially just the object's memory address (or an address of that address, if "double-indirection" is used). The object's true type information is stored with the object, but I don't see that the reference itself contains any such information. Does it?
[ September 01, 2004: Message edited by: marc weber ]

[Peter den Haan]

Originally posted by marc weber:
I read somewhere that it's the reference that's actually being cast or converted, but I'm not convinced this is accurate.

On the language level, the reference is being cast. On the JVM level, of course, it's the runtime type of the actual object that's relevant. The JVM spec requires a runtime check of the object type (checkcast), and the bytecode verification stage means that the compiler has to put that check in. The specification doesn't seem to mandate anything specific on the representation of references. You might also be interested in the description of the checkcast operation.

I think, but am not fully sure, that the answer to your question is that you are both right and wrong You are right because all requirements can be met without run-time tracking of reference types. You are wrong because the reference does have a type and that type is being cast; the evaluation can however happen fully using dataflow analysis in the verification stage. I should emphasise again that this is is only based on my incomplete understanding of JVM internals, so please don't believe me

- Peter

[Ilja Preuss]

Originally posted by marc weber:
I read somewhere that it's the reference that's actually being cast or converted, but I'm not convinced this is accurate. The reference is essentially just the object's memory address (or an address of that address, if "double-indirection" is used). The object's true type information is stored with the object, but I don't see that the reference itself contains any such information. Does it?

Not at runtime. At compile time, though, you could see a reference as a tuple of (<memory for an objects address>, <allowed type of objects> .

[marc weber]

Originally posted by Ilja Preuss:
Not at runtime. At compile time, though, you could see a reference as a tuple of (<memory for an objects address>, <allowed type of objects>

That makes sense.

My impression -- and it's little more than that -- is that reference type is an "association" maintained at the language level by the compiler. I imagine the compiler putting a virtual Post-It on the reference, saying something like, "Note to self: This reference is to a String Object." In other words, reference type is the compiler's own bookkeeping, rather than anything inherent to the reference itself.
[ September 02, 2004: Message edited by: marc weber ]

[Ernest Friedman-Hill]

Originally posted by marc weber:
In other words, reference type is the compiler's own bookkeeping, rather than anything inherent to the reference itself.

Yes.

[Ilja Preuss]

Originally posted by marc weber:

My impression -- and it's little more than that -- is that reference type is an "association" maintained at the language level by the compiler. I imagine the compiler putting a virtual Post-It on the reference, saying something like, "Note to self: This reference is to a String Object." In other words, reference type is the compiler's own bookkeeping, rather than anything inherent to the reference itself.

As I think about it, the type must also be present in the byte code, else compiling against binary libraries wouldn't be fully typesafe (say, if you access a puplic field). I'd guess it's also checked by the verifier at class loading time.

[Peter den Haan]

Originally posted by Ilja Preuss:
As I think about it, the type must also be present in the byte code, else compiling against binary libraries wouldn't be fully typesafe (say, if you access a puplic field). I'd guess it's also checked by the verifier at class loading time.

Yes, and yes, as far as my meager understanding is correct. See the JVM spec bits I linked to above.

- Peter