thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bennett" <>
Subject RE: Does Thrift interoperate with Java beans?
Date Tue, 06 Oct 2015 05:37:47 GMT
Thanks for all the helpful responses. 

I tried to make it clear that what I have is a client-only problem. The server code is unrelated,
not causing any problems and not part of this question. In fact I already have my own IDL
generator, so the Swift-related suggestions are not really all that useful.

The question is specifically about how well the Java generated code can be made to play with
bean-ish code on the client side. The context is a desktop or thick client app with a rich
Java UI that is built to interact with bean code (which in turn has its own persistence or
serialisation or communication layers), and replacing the lower layers with a Thrift API.
I fear I'm getting pushed into creating a bean for each Thrift struct, along with wrappers
for every ctor, getter and setter, and that's not necessarily a place I'd like to get to.
Since beans are fairly common, I wondered if someone had a better answer.

David M Bennett FACS

Andl - A New Database Language -

-----Original Message-----
From: [] On Behalf Of Stuart Reynolds
Sent: Tuesday, 6 October 2015 11:41 AM
Subject: Re: Does Thrift interoperate with Java beans?

Kinda. Sorta.

Vanilla Thrift generates Java data classes that looks pretty beany to me (they have the standard
getters and setters). However, I've always felt that there's a big downside to giving up control
of your server code - not least, you can't add any additional advanced bean annotations (or
any other kind of annotation) to you classes, nor can you directly serialize third party classes
not produced by Thrift.
This often leads to you wrap the serialization, which kinda defeats many of the benefits having
it automated and had me banging my head on the table in dispair.

I've since been using Facebook's Swift project. This lets you
*generate* your thrift IDL from your *existing* server interfaces and bean classes, but also
maintain thirft's extremely efficient serialization (via runtime class generation). The project
has a few design choices I've not a fan of (export classes but not interfaces, has a HUGE
set of dependencies, most unrelated to serialization), but I've made a fork for scala to allow
me to work around the bigger issues. For me, its been hugely efficient at letting my export
any old interface or data structure with no data marshaling steps.

- Stuart

On Mon, Oct 5, 2015 at 4:37 PM, David Bennett <> wrote:
> I have some lumps of code in different languages that I'd like to get to talk to each
other. The server is OK, but the client code makes heavy use of Java beans.
> My question, to those who knows a lot more about Java than I do, is whether there is
some clever way to get Thrift and Java beans to play together, or whether this is an invitation
to getter/setter hell?
> Regards
> David M Bennett FACS
> Andl - A New Database Language -

View raw message