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 <[email protected]> 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 <[email protected]> wrote: > >> On Thu, Jun 13, 2013 at 3:14 AM, David <[email protected]> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
