Re: Define Type at runtime
BGB wrote:
Lew wrote:
BGB wrote:
Lew wrote:
John wrote:
If I have a method:
public void someMethod(Object o){
...
Entity<T> entity;
....
}
How could I define at runtime the type T if I have an Object?
You can do an illegal cast with the help of '@SuppressWarnings("unchec=
ked")' and a 'catch ( ClassCastException exc )'.
You can under certain circumstances use a run-time type token of type =
'Class<T>'.
You can write your method to be type-safe in the first place and avoid=
the problem.
Without some context we can't know what you really want. Your questio=
n is far too non-specific.
and, probably, not to forget "instanceof".
That's pretty useless in this context.
eg, [sic] rather than, say:
Object obja;
try {
SomeObject objb=(SomeObject)obja;
...
}catch(ClassCastException ex)
{
}
one could be like:
if(obja instanceof SomeObject)
{
SomeObject objb=(SomeObject)obja;
...
}
which could be more useful if one wants to do the types N-way...
if(...)
{
...
}else if(...)
{
...
}else ...
or such...
That's bad advice on several fronts. First of all, the OP was asking ab=
out restoring generics information, for which 'instanceof' is not useful, a=
nd second, multi-'if' constructs on type are a red flag of bad design. Don=
't recommend bad design.
AFAICT, the OP was asking about dynamic type checking, which is what
instanceof is for.
They were asking about the generic type, which most emphatically is *not* w=
hat 'instanceof' is for. You even cited the post: "How could I define at r=
untime the type T if I have an Object?" where "T" was the generic type para=
meter in the OP's example. 'instanceof' won't help there. In fact, it wil=
l not even compile.
JLS =A715.20.2
"It is a compile-time error if the ReferenceType mentioned after the instan=
ceof operator does not denote a reifiable type (=A74.7)."
the bigger issue though would be, why the OP was dealing with the case
in the first case (like, yes, does a common base-class exist besides
"Object", or is there a common interface, ...), but failing this, nested=
if/else and instanceof does seem like a valid solution (and is probably=
Wrong.
still better than, say, a series of try/catch blocks intermixed with
return statements).
Except for that failure-to-compile thing.
try {
...
return;
}catch(...) { ... }
try {
...
return;
}catch(...) { ... }
...
but, whatever works...
By which I assume you at least mean compiles.
'instanceof Entity<T>' will not compile.
if-then chains of type comparisons are a major antipattern, a point you glo=
ss over. It means that you aren't using polymorphism and type-safe code. =
It's a Bad Thing.
if (x instanceof Foo)
{
// do one thing
}
else if (x instanceof Bar)
{
// do another thing
}
else if (x instanceof Baz)
{
// OK, this code is far too stupid. Refactor intelligently.
}
....
You're supposed to have
Super foo = obtainASubtypeInstance();
foo.polymorphicMethod();
--
Lew