Is it possiable? Create object via parameter?

[Scott Phelps]

Can you do something like?

public void createObject(Class type, String name){

type name = new type();
// or
type newObject = new type();

}

If so how?

 

[Patricia Shanahan]

Can you do something like?

public void createObject(Class type, String name){

type name = new type();
// or
type newObject = new type();

}

If so how?

You can create an instance given a Class using the method newInstance in
java.lang.Class or in java.lang.reflect.Constructor. Constructor is more
flexible, allowing for parameters. Class is more convenient, if you
don't need parameters.

However, the type of a variable is a compile time issue, not something
you can change at run time. What do you intend to do with the new object?

Patricia

 

[Thomas Weidenfeller]

Can you do something like?

public void createObject(Class type, String name){

type name = new type();
// or
type newObject = new type();

}

If so how?

Just check the API documentation of Class.

/Thomas

 

[Thomas Hawtin]

You can create an instance given a Class using the method newInstance in
java.lang.Class or in java.lang.reflect.Constructor. Constructor is more
flexible, allowing for parameters. Class is more convenient, if you
don't need parameters.

Class.newInstance can throw checked exceptions that it does not declare.
For that reason I'd always go the Constructor route.

Tom Hawtin

 

[Roedy Green]

public void createObject(Class type, String name){

type name = new type();
// or
type newObject = new type();

}

If so how?

It is called reflection. It is for people who enjoy eating with their
hands tied behind their backs.

 

[jan V]

If so how?

It is called reflection. It is for people who enjoy eating with their
hands tied behind their backs.

Well, it has some serious uses. I wrote a Java language interpreter (like
old BASIC interpreters) years ago... without reflection it would have been
impossible.

 

[Scott Phelps]

Class.newInstance can throw checked exceptions that it does not declare.
For that reason I'd always go the Constructor route.

Tom Hawtin

Thanks for the help! I am creating a class that pulls table data and puts it
in it's correct POJO file.

It worked perfectly!

 

[Roedy Green]

Well, it has some serious uses. I wrote a Java language interpreter (like
old BASIC interpreters) years ago... without reflection it would have been
impossible.

JNI, Reflection and ANT are similar. To do simple things in a very
general way you have to write at least 5 times the normal amount of
code. To me it is bit like eating with 4 foot long chopsticks or with
your hands tied behind your back. It can be done, but it not the way
you want to eat normally.

You don't want to use these things just because they are cool or doing
so satisfies a curiosity itch. There has to be a big benefit to make
up for the awkwardness.

 

[John Currier]

Thanks for the help! I am creating a class that pulls table data and puts it
in it's correct POJO file.

It worked perfectly!

I assume that I'm not alone in having no idea what you just said. A
POJO isn't a file..it stands for Plain Old Java Object. Putting table
data into a POJO file does not compute.

John Currier
http://schemaspy.sourceforge.net

 

[Ian Pilcher]

You don't want to use these things just because they are cool or doing
so satisfies a curiosity itch. There has to be a big benefit to make
up for the awkwardness.

Tell that to the folks who decided that interfaces can't have static
methods.

 

[jan V]

JNI, Reflection and ANT are similar. To do simple things in a very
general way you have to write at least 5 times the normal amount of
code. To me it is bit like eating with 4 foot long chopsticks or with
your hands tied behind your back. It can be done, but it not the way
you want to eat normally.

You don't want to use these things just because they are cool or doing
so satisfies a curiosity itch. There has to be a big benefit to make
up for the awkwardness.

I agree with the point you're making, but tell me how to write a Java
interpreter without reflection, if you can. I claim you can't, so the "big
benefit" in this case is "it turns the impossible into the possible." That's
rather a significant benefit, no?

 

[Chris Uppal]

[...] but tell me how to write a Java
interpreter without reflection, if you can.

Byte code generation[*].

Not relevant to the point at hand, I admit ;-)

-- chris

([*] In fact that's how reflective invocation of methods, and access to fields,
is implemented in the recent Sun JDKs)

 

[jan V]

[...] but tell me how to write a Java

interpreter without reflection, if you can.

Byte code generation[*].

Not relevant to the point at hand, I admit ;-)

-- chris

([*] In fact that's how reflective invocation of methods, and access to fields,
is implemented in the recent Sun JDKs)

No way! Really? Can you give me some reference to back this up? This is very
hard to believe....

 

[Chris Uppal]

[...] but tell me how to write a Java
interpreter without reflection, if you can.

Byte code generation[*].
[...]

([*] In fact that's how reflective invocation of methods, and access to
fields, is implemented in the recent Sun JDKs)

No way! Really? Can you give me some reference to back this up?

Back what up ?

The claim that one can use byte-code generation to invoke methods and access
fields is -- I would have thought -- obvious. Note that I'm not claiming that
byecode generation would allow you to discover /what/ members were present;
that would be best handled by reflection. Although, in the situation you
mention, where you have complete control of the invocation environment,
reflection isn't /necessary/. You could still write an interpreter that "knew"
what members existed in the (fixed set of) classes loaded by the primordial
classloader -- say by scanning the JAR(s) -- and which thereafter was in
control of class loading so it also had full information about any other
classes that were loaded dynamically from other places.

Or were you asking for a reference to support the claim that Sun use byte-code
generation in order to invoke methods reflectively ? If so then I refer you to
the source (the full source, not the stuff in src.zip, although the source to
java.lang.reflect.Method does provide some hints). Take a look at the stuff in
the sun.reflect package; the main entry-point is sun.reflect.ReflectionFactory,
and the implementation of sun.reflect.MethodAccessorGenerator is as good a
place to start browsing as any.

-- chris

 

[jan V]

Or were you asking for a reference to support the claim that Sun use
byte-code

generation in order to invoke methods reflectively ?

That's what I would like to see, yes.

If so then I refer you to
the source (the full source, not the stuff in src.zip, although the source to
java.lang.reflect.Method does provide some hints). Take a look at the stuff in
the sun.reflect package; the main entry-point is sun.reflect.ReflectionFactory,
and the implementation of sun.reflect.MethodAccessorGenerator is as good a
place to start browsing as any.

OK, I browsed (quickly), and it does seem Sun are generating classes.. but
my impression was that this was to optimize repeated reflection calls... not
to actually carry out the introspection. That seems to be done by the JVM (I
read a comment about some MagicXXX class being used as a tagging superclass,
to signal the JVM that access checks should be switched off - that comment
would imply there's native stuff in the JVM which does the essence of
reflection.. I could be wrong though. I'd have to read their code a lot more
to really find out what's going on in there.)