I have an interesting problem and I'd like some analysis from more experienced Java programmers.
I have two processes, both running java, which communicate over IPC using serialization. I have a particular interface, MyIfc, which is known to both processes at compile time. Process A needs to be able to treat a reference to this interface as an opaque handle, but process B needs to be able to instantiate and manipulate the concrete class behind it. Simple, right?
However, I would prefer that process A not need to know what the concrete class is, or even have a reference to it at load time.
The problem is serialization. Because the concrete class needs to be deserialized in process A, therefore A needs to have the concrete class on its classpath. But let's pretend for a moment that processes A and B are on separate machines----since they communicate using serialization, this ought to be no different. But there is a requirement that the concrete class implementing MyIfc be present a priori on both machines in order for deserialization to work, and this is what I am struggling with.
My question is, would it be possible to send the .class file from B to A over the link, write it to disk somewhere, and add it to the classpath all at runtime? Effectively hiding the fact that A relies on this class from the user?
You can hot deploy Java classes but I believe you would have to write your own class loader to search for newly deployed classes. Having said that this doesn't seem like the right way to solve the problem. Have you looked at using RMI which handles remote access to classes which aren't available on the callers classpath.
RMI looks great, especially its ability to download remote class definitions for you. However, RMI is not available on Android, which is where I'm working. I already jumped through a few hoops to get Java Beans (mostly) working on Android using Apache Harmony, so maybe I can do that again.
Reply With Quote
Bookmarks