Object Serialization and Remote Method Invocation
This week, we're going to examine two more new additions to Java: Object Serialization and Remote Method Invocation. Be forewarned, these are two somewhat complicated issues (especially the latter), so for now we'll describe more of wha tthey do, as opposed to how they work or how they're used.Although not as concrete and immediately useful as JAR files or the new security tools, the subject is not as abstract as Reflection, and there's a decent chance that one or both of these tools will come in handy for even the "casual" applet programmer at some point or another.
If we had to choose between them, Object Serialization is the feature we prefer. It's simple, powerful, and it does quite well what it was apparently intended to do. And what is that?
Persistence is at the heart of the matter. If you've been programming in Java or some other object-oriented language in recent years, you're well acquainted with the fact that, in order to have your objects available for use, one has to instantiate them. Thus, every time your program starts, it must create all its objects anew from the descriptions you provide in your classes, and then "set them up" in whatever way is required. Usually this entails things like "attaching" them to each other, as we attach buttons to panels when using the AWT, or loading strings into list objects, for example.
Depending on how many objects you typically have in your programs, and how complicated it is to set them all up correctly, this can be burdensome, especially if your program is frequently stopped and restarted. Someone thus eventually came up with the bright idea of object persistence--in which objects, instead of disintegrating every time the program ends, might be completely recorded somehow and then simply loaded again in whatever state they were left.
In the JDK 1.1, although this feature has not been fully realized, we have a new tool that will be instrumental in making it happen--object serialization. This feature allows us to "automatically" convert an object into a format suitable for recording and reloading (or, for instance, transmitting); hence, "serialization," which, for the jargon illiterate, roughly stands for the concept of taking a large entity and turning it into a single-file stream of data.
Like we said, it's simple to use. If you've got an urge to record an object you created in it's present state, whatever that may be, with all of its parts intact, you can easily do it like so:
myDate = new Date(); [... and later on in the program ... ] FileOutputStream myfile = new FileOutputStream("MyDateObject_2-4-97"); ObjectOutput objout = new ObjectOutputStream(myfile); objout.writeObject(myDate);
(If this looks unfamiliar and you need to brush up, just check out the column on input and output streams.)All you need is an output stream--any output stream will do. In our example we use one for output to a file, but it's not specifically important at all. Simply create an
ObjectOutputStreamobject and "attach" it to the regular stream. Then just invoke itswriteObjectmethod on an object, and, like magic, a specially coded "recording" of the object will be sent out on the stream. You can similarly read these recordings back and instantiate the recorded objects. The code preserves all the important aspects of working objects in Java: type information, security information, and even any other objects that your object makes reference to.As stated before, it's simple and powerful. Now, if you write a complicated Java program with lots of objects that collect information as they operate, you can very easily save them all and reload them when the program starts again--even over a network stream, if desired. Thus we have object persistence. You might also, for instance, want to send one running Java program objects from another one; this too is now a fairly simple task.
As for Remote Method Invocation--it's far simpler in theory than it is in practice. The name really does say it all: it allows for one running Java object to invoke a method on another running object--remotely, over a network if necessary.
We're reminded of another Sun invention allowing for remote procedure calling (for C and C++ programs, primarily). This fairly desirable feature allows for all kinds of clever network-based programs. Where before we would have actually had to teach two running programs to "talk" to each other in some intermediate language (called a protocol in the networking world) if we wanted them to exchange information, now when one program might need to get some information from another, on another computer, it need merely invoke a method on that other system (specifically, in our case, on another Java Virtual Machine) and wait for the returned result. This is supposedly much simpler.
Unfortunately, it's not. If there's any feature that we're disappointed with in the new Java release, this is it. It does do the job, but it can be unnecessarily complex and clunky to use, perhaps to the point where teaching your programs to talk to each other explicitly, and inventing a simple protocol for them, might be easier in many situations. This, more than anything else thus far, bears the marks of having been added to the language after the fact, and (we bet) not by the original language designers. We'll talk about how to use it, but it'll take time, and it'll probably be hard to swallow. It was for us, and we've been doing this sort of thing for a while.
Of course, the reason we mention this feature along with object serialization is that they're somewhat related, but we'll get to that in due time. Meanwhile, check out the links, think about the possibilities, and come back again next week for more on the latest in the world of Java.
