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.
hth
-- Ben
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Stuart Reynolds
Sent: Tuesday, 6 October 2015 11:41 AM
To: [email protected]
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 <[email protected]> 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 - andl.org
