I think it is appropriate to keep the "correct" type on things, as using it on the server people will be unhappy using double for purely integral values. So, I think using long for uint32 is correct, but there should be docs explaining that it is slow and should be avoided in the client, and also have the methods taking/returning double.
Is it worth doing to have all the separate isSupported? As someone using it, I would rather have one check that makes sure everything is available and be done with it -- that would mean either saying typed arrays aren't supported due to DataView missing, or else emulating it using the other views (the byte-order swapping for floats would be problematic there, I think). Likewise for Uint8ClampedArray on WebKit. Shared code should be able to instantiate arrays and views, so you need one factory that has a super-source version that instantiates the client-side version. One use case I have in mind is implementing binary protobuf support -- you don't want to have to generate code that is different between the client and server. For the Java/JS array aliasing/copying, enough places have needed this I think it needs to go into c.g.g.core.client with the other JsArray* classes, and everyone can just use that implementation rather than reinventing the wheel slightly differently. I am off today, but I hacked up a proof-of-concept of how to divide into into shared/client/server, and a quick ByteBuffers implementation -- I'll try and post it later today so you can look at it. http://gwt-code-reviews.appspot.com/1621803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
