----- Original Message ----
> From: David Reiss <[email protected]>
> To: [email protected]
> Cc: Greg Stein <[email protected]>; Bryan Duxbury <[email protected]>
> Sent: Thu, August 26, 2010 7:52:24 PM
> Subject: Re: Thrift compiler in Java (have parser, willing to hack)
>
> > 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.
Well someone other than you has offered to do it, so how easy the
task would be isn't all that relevant here. It's whether or not
changing to Java is in the best interests of the project, and
portability concerns alone are far more significant than the
relative ease with which the task can be accomplished.
Is introducing a core dependency on having a java executable
in a user's path really a critical issue nowadays?
This little initiative sounds perfect for a branch/sandbox effort
by interested committers. And if folks want to work on it,
why say no? You can always wait for the work to be finished
to compare it with the C++ version, and either collectively pick
the better option, or go with both.