• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

6 Qs

 
Swamy Nathan
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In their book HFEJB K&B say that when using RMI and passing arguments it is possible that the runtime argument is not actually serializable and if so the exception will be a runtime exception unless if the declared parameter type in the remote business interface method is actually declared as Serializable. (This is what I understand from 2nd Q on page 72.)

Q1) Can I also assume safely that it will be a compile time exception if the declared parameter type in the remote business interface method is actually declared as Serializable or some class that directly or indirectly implements Serializable?

I tried this code based on what was mentioned in the book
HashMap map= new HashMap();
map.put("key","value");
Collection c=map.values();
System.out.println(c instanceof Serializable);
System.out.println(c);
System.out.println(c.getClass());
And got the output
false
[value]
class java.util.HashMap$Values

Q2) Does anyone know of any other situation when a collection is actually non-serializable and has to be made into a ArrayList?



I have a client C and a remote object ro of type say RO on some server. I have a Stub stub of type say Stub on client side. I have a Skeleton skeleton of type say Skeleton on server alongwith ro.
RO has a method method1() which say returns "this". ro actually is not returned but a stub is. That stub would get deserialized at the client code and be instantiated as say stub1.

Q4) I think stub1 & stub are two different object instances.(stub1!=stub) Is that right?

Q5) But stub & stub1 would always give the same same results any time their methods(same method) are invoked as long as ro has same data on the server during those method calls. Is that right? Would they give a equals() test as true?

However it is possible for some method method2 to exist on RO which creates a new RO instance and returns it. So returning stubs is meaningful at times.

Q6) What happens if the new RO instance was a local variable and was therefore garbage collected locally at the server end?( But the stub has been returned.). So what happens if we use this stub at the client and invoke some method on it? Or is it that the new RO instance would not be garbage collected if its stub was returned? If that is the case would it be garbage collected if the returned stub is just ignored. What would happen in such a case?
[ July 21, 2004: Message edited by: Swamy Nathan ]
 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For Q1, I guess the reason why it would be runtime exception but not compilation error is related to the method actually used for java serialization:

ObjectOutputStream.writeObject(Object s)

I guess this method will somehow appear in the generated stub/skeleton (unless there are some other ways to do serialization). And, the method expects Object type - not Serializable. So when compiler doing the checking, whatever type can be passed to the method.

If our remote method is something like this:

public void takeIt(Dog a)

then the compiler will only check if a is Dog type and no compile error even if Dog doesnt implements Serializable. Because in the stub, the code would be

.....
ObjectOutputStream.writeObject(a);
// a is from takeIt(), but who cares if it is Serializable!
....
and the compiler only expects Object type for the argument.
 
Swamy Nathan
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Q1) Can I also assume safely that it will be a compile time exception if the declared parameter type in the remote business interface method is actually declared as Serializable or some class that directly or indirectly implements Serializable?



I guess it has to be so. I dont see how it is ever possible that if Dog had been the parameter type and Dog was declared as serializable any derivative of Dog would be anything other than serializable. The only occassion for a runtime excption instead of a compile time one would be if Dog was not implementing/extending Serializable as a class/interface. And if it were not serializable the person writing the code would be making a design mistake. But it seems to me to be something that the rmic compiler should catch. Seems like a hole that Sun forgot to fill.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic