Can you verify that the same RPC decisions are being made?  For
example, does the code size look about the same, and the RPC policy
files exactly the same?  In particular, I'm worried about the new TICs
being added for things like wildcard types and type parameters.  After
a few minutes of poking, I don't see where those are weeded out, and
indeed I see some places where a type parameter is quietly replaced by
its upper bound.  If there are any differences, a simple way to prevent
them would be to have STOB.build() skip over any type parameters or
wildcard types when it is setting up possiblyInstantiatedTypes and
fieldSerializableTypes.

The rest of this message assumes either everything is still working
the same except for the log messages, or that the above tweak to
STOB.build is made.  In those cases, the patch LGTM, but with some
small nits:

checkTypeInstantable() starts by testing both
tic.hasInstantiableSubtypes() and tic.isInstantiable().  It only needs
to test hasInstantiableSubtypes().

For the listing of subtypes that were considered, I meant just to list
the types, not the types plus all the problems with them.  It's up to
you, though.

I wouldn't expect TypeExposureComputer to need to report any problems.
Did you run any any cases where it should?  Barring an argument to the
contrary, it looks better to not pass ProblemReports into TEC.  The
general idea is that any problem that needs reporting will also be
picked up by STOB proper.

Stepping back, I still suspect we could simplify all this if the
problems were listed in TypeInfoComputed, possibly along with some
other information.  It's just an idea, though.  The patch as is gives
GWT RPC much better logging.

Lex

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to