Sounds definitely like a mistake -- thanks sandymac!

(No comment was entered for this change.)

(No comment was entered for this change.)

The attached patch fixes issues 1161 and 1163.  Seemed like a good idea to put them
together since they impact the same file.

 Issue 1161 : 
We only checked for native methods if the class was automatically serializable. 
Since all of our JRE classes with native methods use custom field serializers we
never saw the native method warning.  When external developers added auto
serializable types to the JRE they did get warnings.  This patch will check any
serializable types for native methods.  The check is skipped if the type is part of
the JRE emulation.  We assume that all types whose package names begin with "java."
are not part of our JRE.    This does not account for javax and org.* packages which
are part of the real JRE.

 Issue 1163 :
There were a few problems with this code.  First, when generating a log message we
did not store whether or not it was a warning or an error.  If the type was seen
multiple times, it was possible that what was previously a warning would be treated
as an error.

Second, abstract classes that did not have any instantiable subtypes would be
considered an error.

Third, I removed several warnings about assignment to parameters and member
visibility causing synthetic access methods to be generated.

	issues_1161_1163-r1205.patch
	27.6 KB Download

(No comment was entered for this change.)

Please review this latest patch.  It addresses  issue 1129 , also removed some test
code which was no longer necessary.

The fix is that if we are in a manually serialized type that uses Object or Object[]
we will consider all serializable subtypes of Object.  Without being able to deal
with arrays dynamically and without giving additional information to CFS this is the
best that we can do.  We should be able to handle this correctly in RPC v2.

	issues_1129_1161_1163-r1205.patch
	42.2 KB Download

(No comment was entered for this change.)

I'm not clear on what UnserializableClass with a custom serializer actually means or
tests, but otherwise everything on the test end looks good.. glad to see the
workaround is no longer needed.

As for SerializableTypeOracleBuilder:
227: This would seem to make unserializable a type which had generated only warnings;
is this the intent?
669: I'm not clear why this line was added.
654(old rev): Not clear on why this was removed.

General:
- I notice not all warnings logged become warned issues attached to that type; is
this the intent?
- I see a few lines needing format (whitespaces)

Otherwise, LGTM.

Committed as r1228.

1.4 RC2 now released.