[ 
https://issues.apache.org/jira/browse/THRIFT-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211053#comment-13211053
 ] 

Roger Meier commented on THRIFT-872:
------------------------------------

Dave,
as mentioned by Bryan, please rebase the patch and we will commit it!

Yes, size matters;-)
                
> 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
>         Attachments: java-primitive-872-v2.patch, 
> java-primitive-872-v3.patch, 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.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to