I agree; this seems like a workaround for one application that picked the wrong datatype. Maybe we should warn about BigDecimal being slow somewhere? If someone wants to do some performance tests of GWT-RPC serialization, publishing the results would be useful to the community.
My recommendation in this case would be create a new class named "Id" or Key" that simply contains the BigDecimal, then modify the code to use it, then change the implementation to store the data in a string field instead. In the end you'll have more readable code. - Brian On Thu, Jun 13, 2013 at 12:03 PM, David <david.no...@gmail.com> wrote: > John, > > Well, if I don't have support for this patch then I better stop working on > it. I can understand that this is not seen as a priority for GWT. Worst > case I just replace the BigInteger/BigDecimal class in the project itself, > that is basically what I did right now. > > Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. > The Oracle JDBC drivers return > a BigInteger if you force it to the extremes. > > Changing the application is not feasible, that will be too much work, we > are talking about many thousands of dependencies in a huge codebase where > BigIntegers and BigDecimals are used - while handling this optimisation on > the RPC level can be done in just a few lines of code. > > In many cases we send large lists of objects that contain BigInteger, > BigDecimals but only a few will actually be interacted with. So in that > case we only need to convert the Strings to BigInteger (or BigDecimal) when > really needed. > > David > > On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin <j...@jaet.org> wrote: > >> 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. >> >> >> > > -- > 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. > > > -- 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.
