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 13:22:45 GMT
Thanks for the answer. I'm not a Java guy and I didn't know that the Thrift compiler had a
'beans' option. Perhaps I forgot to read the documentation?-) 

What I was hoping for is what you've just done: tell them they play kind of OK with a little
tweaking. It seems that if I name things right and use the 'beans' option then there is a
good chance a lot of the classes/getters/setters will line up and I won't need to write wrappers
for the wrappers.

Re Swift: I'm just trying to limit the number of technologies I have to learn, and the answers
all seemed to have 'server' and 'generate IDL' in them, which are the bits I don't need. As
long as what you said goes for the client end, I'm happy to give it a go. I don't really care
if the code is 'clean' yet -- just getting something to work would be nice.

David M Bennett FACS

Andl - A New Database Language -

-----Original Message-----
From: BCG [] 
Sent: Tuesday, 6 October 2015 11:59 PM
Subject: Re: Does Thrift interoperate with Java beans?

On 10/06/2015 01:37 AM, David Bennett wrote:
> 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.

Swift supports clients as well as servers, so I'm not really sure why you would say the suggestions
are not useful just based on that.  
Perhaps that is besides the point though.
> 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.

Not trying to beat a dead horse here, just trying to make it clear that this was the question
we were trying to answer.  Since you already have IDL, you can use Swift's code generator
to automatically create beans for all of your structs.  You *probably* could use the regular
Thrift compiler to do that too with the "beans" option to the Java generator, but Swift's
"beans" are much cleaner and closer to what you would expect.  That will work well for the
structs, so that you don't have to create wrappers for each one.  For the services (whether
you use Thrift or Swift proper) you will probably need to write some code to bind the client
stubs to some underlying Thrift protocol/transport, but that should be straightforward and
if you are just using one endpoint that can use TMultiplexedProtocol, most likely could be
generic across all of the whole application.

tl;dr - you probably could do this with the regular Thrift compiler too, but the use case
you are describing is pretty much what Swift seems to be have been designed to do.


-- Ben

> -----Original Message-----
> From: [] On 
> Behalf Of Stuart Reynolds
> Sent: Tuesday, 6 October 2015 11:41 AM
> To:
> 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