On Thu, Jun 13, 2013 at 3:14 AM, David <david.no...@gmail.com> wrote:
> The lazy parsing would only happen during deserialisation in the client. I > think it is safe to assume that a BigInteger created through toString on > the server will not result in a parse exception in the client code - or are > there known incompatibilities ? > > I don't want that the regular constructor of BigInteger( String ) or > BigInteger( String, int) would behave differently than before. Not even in > the client when those BigInts are created in the client. That's why I was > asking about the possibility to have different serialisers on client and > server side. > > As the why, well currently the custom field serializer converts the > BigInteger to a String, the client side needs to parse the string and > convert it to an int array, which involves multiple substring, > Integer.parseInt and multiply and add operations. Somehow IE8 has a problem > with this. IE9 and other browsers are more efficient, but still that is a > lot of CPU operations that can be avoided in my use case. > > In my particular use case they used BigInteger to represent a key in the > database (oracle uses sequence numbers that are bigger than what can be > represented with long). That might have not been the best idea, but those > decisions have been made a long time ago, when I was not around. On the > server side there is a usage of equals and compareTo happening, which would > be hard to implement without a BigInteger, so there is logic in the choice. > They obviously don't want to have an extra layer of objects to avoid the > BigInteger in the GWT client since a lot of code is independent of client > or server, this would hinder code sharing between the tiers. > > On the client side these id's are only send forth and back between client > and server, no operation is ever performed, so making the custom field > serialiser and the BigInteger cooperate gives a big performance > improvement. They only operation needed on the client-side is equals, which > can also be optimized to do a String comparison when bother have not been > parsed after RPC. > I'm beginning to think such a change does not belong in GWT. In your example, wouldn't you be better served by only sending strings to the client rather than BigDecimals, if they client never does anything with them but send them back? I think it is going to be pretty rare in normal situations that you instantiate a BigDecimal but never actually use it in the client, so it seems the special-case hack for your use-case should be performed in your code instead. Too often people want to send things to the client that really don't belong there, and that includes particular representations of it. I know DTOs are extra work over just shipping your regular objects over the wire and GWT RPC makes that easy, but in many cases it is the wrong thing to do. Think about if you were building a proto for the communication -- would you send the data in the current form? If not, you shouldn't be sending it that way via RPC just because it is easy to do so. BTW, I thought Oracle sequence numbers did fit in long (aren't they int64?) -- at least all the JDBC code I see for manipulating them stores them in a Java long. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
