I'm not really motivated that the pain of typing "aptitude install" or "port install" should be a major decision point in how to write code, though I don't think boost is terribly integral to the generator right now. I would also strongly oppose removing it from runtime.
I'm also not motivated that the code will be easier to maintain or develop in Java than C++. Code generators are a PITA. The current code could be cleaned up a bit, but I don't believe Java will improve it any over C++. Quite a few people have extensions or patches that live on top of the current code, and hopefully a good number of them will eventually be contributed into the main code base. Even if there is sufficient interest to rewrite the compiler in Java, a substantial amount of work would be involved by many people to match that change. Some people won't. C++ wouldn't be my first choice of a language for the generator. Java probably wouldn't be, either. But C++ isn't blocking improvement to thrift. Bruce ----- Original Message ----- From: "David Reiss" <[email protected]> To: "Greg Stein" <[email protected]> Cc: [email protected], "Bryan Duxbury" <[email protected]> Sent: Thursday, August 26, 2010 5:06:09 PM Subject: Re: Thrift compiler in Java (have parser, willing to hack) I'll get rid of Boost. (From the code generator. Not the C++ runtime library.) On 08/26/2010 05:05 PM, Greg Stein wrote: > On Thu, Aug 26, 2010 at 19:52, David Reiss <[email protected]> > wrote: >>> This has been >>> a hassle for httpd and svn... those two projects generally do *not* >>> provide binaries, and rely on downstream packagers. Of course, we >>> could also rely on packagers. >> >> That sounds fine to me. >> >>> I'm more comfortable with C++ than Java, but it seems easier to use >>> compiler subsystems (like ANTLR) and other tools in Java. >> >> My understanding was that ANTLR serves the same purpose as lex and >> yacc, which are already used by Thrift. >> >>> And back to >>> the deployment question regarding dependencies: will the packagers >>> have all the deps available? Compare that to shipping one .jar. >> >> The Thrift compiler doesn't have any runtime dependencies other than >> system libraries. I think the few compile-time dependencies it has >> can be eliminated far more easily than rewriting several thousand >> lines of code. > > I tend to agree, but a Java implementation *is* intriguing. > > I would suggest that the Java-based compiler be checked into a new > subdir for people to look at an experiment with. (I like to avoid a > branch if experimental code can safely live compartmentalized on > trunk) Then we can make a better-informed decision as a community on > where to go. > > If somebody can say, "I'll get rid of Boost", then I'd be +1 on > sticking to C++. > > Cheers, > -g
