Overriding existing Serializeable writeObject ?

[jprogrammer]

I have a rendering class that extends AWT Panel for drawing purposes. I
made this class Serializable so that I can send it over the socket. The
problem I found out is that my implementation of writeObject () and
readObject() for my rendering frame is completely ignored!! Panel class's
default writeObject, readObject is invoked instead. I tested this using
println(). How do I fix this? Here's some code out of my class:

public class DrawFrame extends Panel implements Serializable,MouseListener,
MouseMotionListener{


public int side1[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
public int side2[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
public int side3[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
public int side4[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
public int side5[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
public int side6[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};

//------------------
private void writeObject(ObjectOutputStream out)
{
try{
for(int i=0;i<9;i++)
{
out.writeInt(side1);
out.writeInt(side2);
out.writeInt(side3);
out.writeInt(side4);
out.writeInt(side5);
out.writeInt(side6);
}

}
catch(IOException e)
{
//System.out.println(e);
}

}
private void readObject(ObjectInputStream in)
{
try{
for(int i=0;i<9;i++)
{
side1=in.readInt();
side2=in.readInt();
side3=in.readInt();
side4=in.readInt();
side5=in.readInt();
side6=in.readInt();
}
}
//catch(ClassNotFoundException e){}
catch(IOException e){}

}

 

[Lothar Kimmeringer]

I have a rendering class that extends AWT Panel for drawing purposes. I
made this class Serializable so that I can send it over the socket. The
problem I found out is that my implementation of writeObject () and
readObject() for my rendering frame is completely ignored!! Panel class's
default writeObject, readObject is invoked instead. I tested this using
println(). How do I fix this? Here's some code out of my class:
[...]

private void writeObject(ObjectOutputStream out)
[...]
private void readObject(ObjectInputStream in)

You didn't read the API or didn't understand it:

Classes that require special handling during the
serialization and deserialization process must
implement special methods with these exact signatures:

private void writeObject(java.ibjectOutputStream out)
throws IOException
private void readObject(java.ibjectInputStream in)
throws IOException, ClassNotFoundException;

Your signatures miss the throws-parts.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Sudsy]

I have a rendering class that extends AWT Panel for drawing purposes. I
made this class Serializable so that I can send it over the socket. The
problem I found out is that my implementation of writeObject () and
readObject() for my rendering frame is completely ignored!! Panel class's
default writeObject, readObject is invoked instead. I tested this using
println(). How do I fix this?

<snip>

The javadocs specify:
"Classes that require special handling during the serialization and
deserialization process must implement special methods with these exact
signatures:

private void writeObject(java.ibjectOutputStream out)
throws IOException
private void readObject(java.ibjectInputStream in)
throws IOException, ClassNotFoundException;"

Your classes don't throw the required exceptions and so don't match
the signatures. The javadocs should always be your first point of
reference...

 

[Roedy Green]

The
problem I found out is that my implementation of writeObject () and
readObject() for my rendering frame is completely ignored!!

see http://mindprod.com/jgloss/serialization.

Did you leave out an "implements" anywhere?

Do your method signatures exactly match?

 

[Paul]

Oh I thought the methods "threw" the exceptions and i was supposed to catch
them. I guess i completely misunderstood. Now, do i have to throw
exceptions in any particular order?

I have a rendering class that extends AWT Panel for drawing purposes. I
made this class Serializable so that I can send it over the socket. The
problem I found out is that my implementation of writeObject () and
readObject() for my rendering frame is completely ignored!! Panel class's
default writeObject, readObject is invoked instead. I tested this using
println(). How do I fix this? Here's some code out of my class:
[...]

private void writeObject(ObjectOutputStream out)
[...]
private void readObject(ObjectInputStream in)

You didn't read the API or didn't understand it:

Classes that require special handling during the
serialization and deserialization process must
implement special methods with these exact signatures:

private void writeObject(java.ibjectOutputStream out)
throws IOException
private void readObject(java.ibjectInputStream in)
throws IOException, ClassNotFoundException;

Your signatures miss the throws-parts.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Roedy Green]

Oh I thought the methods "threw" the exceptions and i was supposed to catch
them. I guess i completely misunderstood. Now, do i have to throw
exceptions in any particular order?

No.
See http://mindprod.com/jgloss/serialisation.html
See http://mindprod.com/jgloss/serialisation.html
See http://mindprod.com/jgloss/serialisation.html
See http://mindprod.com/jgloss/serialisation.html

 

[Tony Morris]

Your classes don't throw the required exceptions and so don't match

the signatures. The javadocs should always be your first point of
reference...

A method signature is strictly defined by its name and (order and type) of
its parameters.
The declared exceptions are NOT part of the method signature.
Another misconception is that the return type of a method is part of its
signature, which is incorrect.

// same signature
void m(int i, String s)
int m(int i, String x) throws java.io.IOException
String m(int x, String t) throws RuntimeException

// different signature to those above
void m(String s, int i) throws java.io.Exception
void m(int i)
void mm(int i, String s)

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Lothar Kimmeringer]

Oh I thought the methods "threw" the exceptions and i was supposed to catch
them. I guess i completely misunderstood. Now, do i have to throw
exceptions in any particular order?

No, just put away the try-catch-blocks and add the throws-
Statement in the signature of your method. You should catch
the exceptions where you _use_ the serialization of the
object.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Lothar Kimmeringer]

A method signature is strictly defined by its name and (order and type) of
its parameters.

In this case it was meant that way, that
you have to declare the method exactly as being described
in the Javadocs

The declared exceptions are NOT part of the method signature.
Another misconception is that the return type of a method is part of its
signature, which is incorrect.

I can try that later, but AFAIR the compiler don't accept
methods with the same name and parameters but different
return-types and you get compile-errors as well when you
leave away or add exceptions to methods that are declared
in superclasses.

Google tells me I'm right and Patrick Niemeyer writes the
same in his book "Exploring Java":

A method signature is a collection of information about
the method, as in a C prototype or a forward function
declaration in other languages. It includes the method's
name, type, and visibility, as well as its arguments
and return type.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Andrew Thompson]

I was skeptical so I went on a long hunt
at Sun to try and nail it down.. I saw one
reference that suggested Tony was right,
but it did not seem definitive to me.

....

I can try that later, but AFAIR the compiler don't accept
methods with the same name and parameters but different
return-types and you get compile-errors as well when you
leave away or add exceptions to methods that are declared
in superclasses.

Then I thought to toss that and try it..
<sscce>
import java.io.IOException;

public interface ImplementThis {
public abstract String getTheStuff() throws IOException;
}

class Implementor implements ImplementThis {
public String getTheStuff() {
return "";
}
}
</sscce>

Compiles just fine..

So, no - I now have to concede I have
no idea why your code is failing, maybe
we need to go to help level 2..
<http://www.physci.org/codes/sscce.jsp>

And note that URL does not refer to
'some code' from your class, but a self
contained example that fails.

 

[Tony Morris]

You'll find that what I mentioned is also in parallel with what you said.
A method signature is defined exactly as I described.
There has been no contradiction to that in your statements above.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform