[jira] Updated: (THRIFT-872) Add 'primitive' option to 'Java' code generator

["Dave Engberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dave Engberg updated THRIFT-872:
--------------------------------

    Attachment: java-primitive-872.patch

> Add 'primitive' option to 'Java' code generator
> -----------------------------------------------
>
>                 Key: THRIFT-872
>                 URL: https://issues.apache.org/jira/browse/THRIFT-872
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Java - Compiler
>    Affects Versions: 0.4
>            Reporter: Dave Engberg
>             Fix For: 0.5
>
>         Attachments: java-primitive-872.patch
>
>
> I'm attaching a patch that modifies 0.4.0 to add a new 'primitive' compiler option to the Java code generator that will produce a style of code that reduces library dependencies for generated struct and service interfaces.  This will make the generated code easier to use in some contexts and more compatible with generated code from prior Thrift releases.
> The 'primitive' option changes generated code in the following ways:
> *  Removes dependencies on:  BitSet, ByteBuffer, and the third-party org.slf4j.Logger*
> *  The 'isset' vector is implemented via boolean[] instead of BitSet
> *  The 'Iface' interface for service 'Foo' is moved from an inner class to top-level FooIface.jar (and replaced with dummy Foo.Iface which just extends FooIface)
> *  'binary' fields from the IDL are changed from ByteBuffer back to byte[]
> The patch also includes runtime support library changes:
> *  Added writeBinary(byte[]) and readBytes() methods to TProtocol to read and write byte[] primitives
> *  Added TBaseHelper.toString(byte[],StringBuilder)
> To use (e.g.):  thrift -r --gen java:beans,primitive Foo.thrift
> Rationale:
> 1)  The generated structures and services are more compatible with previous versions (in particular, v 0.2.0), requiring fewer code changes for existing projects upgrading to 0.4.0.
> 2)  The generated POJO structures and service interfaces have a much lower external dependency "footprint", so may be used more easily in platforms and libraries.  For example, the structure *.java files and the FooIface.java files may be used within restricted environments like GWT, which don't support java.nio.ByteBuffer, java.util.BitSet, or org.slf4j.*  (http://www.projectpossibility.org/projects/word_prediction/gwt-linux-1.4.60/doc/html/jre.html)
> 3)  In some contexts, 'binary' data fields may require fewer lines of code to juggle and serialize slightly faster.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Updated: (THRIFT-872) Add 'primitive' option to 'Java' code generator

[Dave Engberg <de...@evernote.com>]

Yeah, I think we're just on the third wave of style for the Java project:
The first wave was the original Facebook bare C-style structs with 
public members.
The second wave was the JDK4-compatible JavaBeans with primitives and 
low dependencies.
I think we're deep into the third wave of style, with heavier metadata, 
generics and runtime dependencies.

When we added the JavaBeans stuff in the second wave, we preserved 
options to for non-Bean generation to preserve backward compatibility.


On 8/30/10 1:34 PM, Bryan Duxbury wrote:
> I wish we could have just one style, but I think it's pretty clear that
> different people are going to keep wanting a variety of options on or off.
> Usually you are separated from other coders' code generator decisions by the
> transport, but I don't really know of a way around that with an embedded
> server.

Re: [jira] Updated: (THRIFT-872) Add 'primitive' option to 'Java' code generator

[Bryan Duxbury <br...@rapleaf.com>]

I wish we could have just one style, but I think it's pretty clear that
different people are going to keep wanting a variety of options on or off.
Usually you are separated from other coders' code generator decisions by the
transport, but I don't really know of a way around that with an embedded
server.

On Fri, Aug 27, 2010 at 1:17 AM, Mathias Herberts <
mathias.herberts@gmail.com> wrote:

> Thanks for contributing this.
>
> On the minus side, I don't like the idea of having several types of
> Java code generated from one IDL as this might lead to some problems
> later.
>
> One example I ran into is when running an embedded Cassandra in some
> tests. All Java code I generate from Thrift IDLs uses bean syntax,
> this is not the path that was choosen by the Cassandra folks,
> therefore to access the embedded Cassandra using the generated Client
> code (bean style), you need to remove all other generated classes
> otherwise the embedded Cassandra won't work.
>
> So my wish would be for one and only one type of Java code being generated.
>
>
> Mathias.
>

Re: [jira] Updated: (THRIFT-872) Add 'primitive' option to 'Java' code generator

[Mathias Herberts <ma...@gmail.com>]

Thanks for contributing this.

On the minus side, I don't like the idea of having several types of
Java code generated from one IDL as this might lead to some problems
later.

One example I ran into is when running an embedded Cassandra in some
tests. All Java code I generate from Thrift IDLs uses bean syntax,
this is not the path that was choosen by the Cassandra folks,
therefore to access the embedded Cassandra using the generated Client
code (bean style), you need to remove all other generated classes
otherwise the embedded Cassandra won't work.

So my wish would be for one and only one type of Java code being generated.


Mathias.