Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Low-latency alternative to Java Object Serialization Date: Tue, 4 Oct 2011 08:55:11 -0700 (PDT) Organization: http://groups.google.com Lines: 46 Message-ID: <1913073.233.1317743711391.JavaMail.geo-discussion-forums@prib32> References: <23089865.2265.1317485980290.JavaMail.geo-discussion-forums@preb19> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 65.50.220.43 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1317744723 17729 127.0.0.1 (4 Oct 2011 16:12:03 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 4 Oct 2011 16:12:03 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=65.50.220.43; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8531 Tom Anderson wrote: > Lew wrote: >> Use JAXB to generate the classes used to process that schema and=20 >> incorporate those classes into the protocol at both ends. >> >> Fast, standard and fairly low effort and low maintenance, assuming you= =20 >> have version control and continuous integration (CI). >> >> By "fast" I mean both to develop and to operate. >=20 > Interesting. I do not believe this to be true. Specifically, i believe=20 > that: (a) developing an XML-based transfer format using JAXB will take=20 > considerably more effort than using standard serialization, or an equally= =20 > convenient library such as JBoss Serialization, although still not a larg= e=20 > amount of effort, certainly; (b) the data will be larger than=20 > with standard serialization (because the "object graph overhead" is not= =20 > actually that large, and XML is much less space-efficient than=20 > serialization's binary format); and (c) the speed of operation, even=20 > assuming an infinitely fast network, will be lower. >=20 > One get-out clause: for very short streams (one or a few objects), XML=20 > might beat standard serialization for space and speed. Standard=20 > serialization does have some per-class overhead, which is=20 > 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 us= e the absolute defaults, but the world is littered with projects that had m= aintenance issues because serialization was done simple-mindedly. /Effecti= ve Java/ devotes an entire chapter to the topic. JAXB solutions, and I've = made several, are very straightforward. Most of the effort goes into schem= a design, which is parallel to modeling so not even an overhead. I do thin= k JAXB wins, but on balance assess that a competent programmer could do eit= her one well with more-or-less similar effort. Fast to perform - XML is fast enough. Compressed, its bandwidth is not egr= egious. Overall I/O considerations should dominate, but I'll take a slight= loss for the safety benefits of JAXB. --=20 Lew