This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Object serialization patch


Jeroen Frijters wrote:
Hi,


Here is a new patch I propose. I've taken the suggestion into account and fix another small error reporting problem.


I don't understand checkTypeConsistency, it looks odd and I'm having a
hard time believing that it is correct. BTW, Shouldn't "nonPrimitive" be
named "primitive"?

The problem if you sort fields using ObjectStreamField.compareTo is that you separate names which are alphabetically sorted. I will explain this on the following example.


Imagine that in the stream you have the following field names:

int a;
int e;
String b;
String d;

They will be sorted as: a, e, b, d. (They will be written as a1, e1, b1, d1).

Now the class may declare the same field names but with different types:

int a;
String e;
String b;
String d;

And they will be sorted as: a, b, d, e. (They will be written as a2, b2, d2, e2).

Now we want to check that the types are consistent between the stream and the class. Previously we compared a1 with a2, b1 with b2, d1 with d2 and the code was generating two more extra fields: e1 and e2 (aka int e and String e). They represent the same field but with two different types which is wrong.

Now checkTypeConsistency compares two field pools. We extract the non primitive fields F1 from the first pool and the primitive fields F2 from the second pool. If we find a field which has the same name both in F1 and F2 there is an inconsistency.

This operation must be done both when the first pool is the "stream" fields and the second pool the "class" fields, and when the roles are reversed.

I think that 'nonPrimitive' is correctly named as the primitive fields came in first and we are looking for the non primitive fields.


Also, I really don't like the type checking being done in the various setXxxField methods, there is no reason to do this every time, it can be done once when the fields are mapped.

Yes, I'm also not completely satisfied with this method. But there exists cases where it is needed. For example, if serialPersistentFields declares class types wrongly. The types are not checked previously in that case and this results in an IllegalArgumentException (which is wrong). The solution would be to check the types of all fields when we are building the ObjectStreamClass from serialPersistentFields.



Regards, Guilhem.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]