Using my own ClassLoader

[Matthias]

Hi there,

suppose you want to send a class via network to your final app. The
app will get an instance of this class and start working with it. So
far so good. BUT "working with it" means in reality to invoke methods
in such a way as

object.doSomething(withMe);

And that's my question: How (the hell) can one compile a program on
the client's side that doesn't have a clue of a class (because it's
beeing sended when runnig) and, furthermore, of objects coming from
these classes?

My current solution is to "pseudo implement" every method for the
client like

public retValue doSomething(inValue in) {
return null;
}

You cannot work with an object of this class, of course but the
compiler is happy to know the class/methods. I get a real instance
from the transmitted class using the newInstance()-method.

I don't think that implementing "pseudo methods" on the client's side
is the right way to do it - however, it's working.

Thanks for your response.
90210

 

[Thomas Weidenfeller]

And that's my question: How (the hell) can one compile a program on
the client's side that doesn't have a clue of a class (because it's
beeing sended when runnig) and, furthermore, of objects coming from
these classes?

E.g. Interfaces or reflection. Any good text book about Java, and the
tutorials on Sun's Java web site will tell you the details.

/Thomas

 

[John C. Bollinger]

Hi there,

suppose you want to send a class via network to your final app. The
app will get an instance of this class and start working with it. So
far so good. BUT "working with it" means in reality to invoke methods
in such a way as

object.doSomething(withMe);

And that's my question: How (the hell) can one compile a program on
the client's side that doesn't have a clue of a class (because it's
beeing sended when runnig) and, furthermore, of objects coming from
these classes?

One can attempt to use reflection, but the basic answer is "you can't do
that."

My current solution is to "pseudo implement" every method for the
client like

public retValue doSomething(inValue in) {
return null;
}

Hmmm. Sounds a lot like an interface to me, only burdened with a stub
implementation. Oddly enough, in cases where you don't know at
compile-time the exact class of an object that you need to use, a
typical strategy is to use it via an interface that its class is known
to implement. That demands that you know at compile-time that the class
in question will implement a known interface, but you can't reasonably
get away with less without going to great lengths and either directly or
indirectly using reflection. Non-trivial reflection-based solutions
that are not equivalent to the known-interface solution always require
user interaction.


John Bollinger
(e-mail address removed)