http://gwt-code-reviews.appspot.com/1463809/diff/1/user/src/com/google/gwt/user/rebind/rpc/CachedRpcTypeInformation.java File user/src/com/google/gwt/user/rebind/rpc/CachedRpcTypeInformation.java (right):
http://gwt-code-reviews.appspot.com/1463809/diff/1/user/src/com/google/gwt/user/rebind/rpc/CachedRpcTypeInformation.java#newcode166 user/src/com/google/gwt/user/rebind/rpc/CachedRpcTypeInformation.java:166: // we have a type that is an array with a primitive leafType On 2011/06/24 22:56:41, jbrosenberg wrote:
Well, it's a recursive call on the leafType, which in turn can arrive
here. If
the leafType is a JPrimitiveType, then it will behave as previously.
The change
is to handle if the leaf type is a JRawType, which in turn will be
handled by
the second recursive call, and then will end up in the JRealClassType
case above
(JGenericType is a sub-class of JRealType).
I understand what you're saying, but in the previous code the path to get to this check was direct, so the comment makes sense there. Specifically, you can see typeToCheck get assigned to the leafType, when it's not JRawType or JRealClassType. In this case, you're flat out testing for JPrimitiveType, and it may just happen to come through from a recursive call involving a leafType. For example, in the previous code if a JPrimitiveType was passed directly, then an assert on instanceof JRealClassType would fail. In this code, if you passed a JPrimitiveType directly, it would return Long.MAX_VALUE. http://gwt-code-reviews.appspot.com/1463809/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
