Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8531

Re: Low-latency alternative to Java Object Serialization

Show key headers only | View raw

Tom Anderson wrote:
> Lew wrote:
>> Use JAXB to generate the classes used to process that schema and 
>> incorporate those classes into the protocol at both ends.
>>
>> Fast, standard and fairly low effort and low maintenance, assuming you 
>> have version control and continuous integration (CI).
>>
>> By "fast" I mean both to develop and to operate.
> 
> Interesting. I do not believe this to be true. Specifically, i believe 
> that: (a) developing an XML-based transfer format using JAXB will take 
> considerably more effort than using standard serialization, or an equally 
> convenient library such as JBoss Serialization, although still not a large 
> amount of effort, certainly; (b) the data will be larger than 
> with standard serialization (because the "object graph overhead" is not 
> actually that large, and XML is much less space-efficient than 
> serialization's binary format); and (c) the speed of operation, even 
> assuming an infinitely fast network, will be lower.
> 
> One get-out clause: for very short streams (one or a few objects), XML 
> might beat standard serialization for space and speed. Standard 
> serialization does have some per-class overhead, which is 
> disproportionately expensive for short streams.

Well, I haven't measured, but let's to a little gedankenexperiment.

Fast to develop - serialization is actually tricky to do right.  You can use the absolute defaults, but the world is littered with projects that had maintenance issues because serialization was done simple-mindedly.  /Effective Java/ devotes an entire chapter to the topic.  JAXB solutions, and I've made several, are very straightforward.  Most of the effort goes into schema design, which is parallel to modeling so not even an overhead.  I do think JAXB wins, but on balance assess that a competent programmer could do either one well with more-or-less similar effort.

Fast to perform - XML is fast enough.  Compressed, its bandwidth is not egregious.  Overall I/O considerations should dominate, but I'll take a slight loss for the safety benefits of JAXB.

-- 
Lew

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Low-latency alternative to Java Object Serialization Giovanni Azua <bravegag@hotmail.com> - 2011-10-01 14:46 +0200
  Re: Low-latency alternative to Java Object Serialization Lew <lewbloch@gmail.com> - 2011-10-01 09:19 -0700
    Re: Low-latency alternative to Java Object Serialization Robert Klemme <shortcutter@googlemail.com> - 2011-10-01 21:13 +0200
      Re: Low-latency alternative to Java Object Serialization jebblue <n@n.nnn> - 2011-10-01 14:35 -0500
        Re: Low-latency alternative to Java Object Serialization Robert Klemme <shortcutter@googlemail.com> - 2011-10-02 11:07 +0200
        Re: Low-latency alternative to Java Object Serialization Roedy Green <see_website@mindprod.com.invalid> - 2011-10-03 11:43 -0700
    Re: Low-latency alternative to Java Object Serialization Tom Anderson <twic@urchin.earth.li> - 2011-10-03 19:24 +0100
      Re: Low-latency alternative to Java Object Serialization Roedy Green <see_website@mindprod.com.invalid> - 2011-10-04 02:45 -0700
      Re: Low-latency alternative to Java Object Serialization Lew <lewbloch@gmail.com> - 2011-10-04 08:55 -0700
  Re: Low-latency alternative to Java Object Serialization markspace <-@.> - 2011-10-01 09:48 -0700
    Re: Low-latency alternative to Java Object Serialization Roedy Green <see_website@mindprod.com.invalid> - 2011-10-04 02:51 -0700
  Re: Low-latency alternative to Java Object Serialization Robert Klemme <shortcutter@googlemail.com> - 2011-10-02 11:10 +0200
  Re: Low-latency alternative to Java Object Serialization Tom Anderson <twic@urchin.earth.li> - 2011-10-03 19:15 +0100
  Re: Low-latency alternative to Java Object Serialization Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-02 11:50 +0000

csiph-web