I’m confused on what you mean by “bean”. A bean is just a class with getters/setters for each property, a no arg constructor, that is serializable. The thrift generated code meets #1, and #2, probably not #3 but they are thrift serializable so maybe that can be considered an equivalent.
What about the thrift generated classes doesn’t work with your code? -Matt For client side code I just use the thrift > On Oct 6, 2015, at 1:37 AM, David Bennett <[email protected]> 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. > > 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. > > Regards > David M Bennett FACS > > Andl - A New Database Language - andl.org > > > -----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 >> >> >
