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

["Bryan Duxbury (JIRA)" <ji...@apache.org>]

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

Bryan Duxbury commented on THRIFT-872:
--------------------------------------

What about making TProtocol's readBinary method non-abstract like this:

{code}
public final byte[] readBytes() {
  ByteBuffer buf = readBinary();
  byte[] bytes = new byte[buf.capacity()];
  buf.get(buf);
  return buf;
}
{code}

I'm not crazy about having two separate implementations of readBinary in TBinary protocol. I'd like to find a way for them to share code if that's feasible.

You've introduced some tabs into t_java_generator.

Everything compiles fine and doesn't break any tests, so I'm inclined to believe things are all good. However, it's worth noting that essentially none of the changes you've made are covered by the existing tests.



> 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] Commented: (THRIFT-872) Add 'primitive' option to 'Java' code generator

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

On Mon, Aug 30, 2010 at 20:28, Bryan Duxbury (JIRA) <ji...@apache.org> wrote:
>
>    [ https://issues.apache.org/jira/browse/THRIFT-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904274#action_12904274 ]
>
> Bryan Duxbury commented on THRIFT-872:
> --------------------------------------
>
> What about making TProtocol's readBinary method non-abstract like this:
>
> {code}
> public final byte[] readBytes() {
>  ByteBuffer buf = readBinary();
>  byte[] bytes = new byte[buf.capacity()];
>  buf.get(buf);
>  return buf;
> }
> {code}

allocating buf.capacity() will allocate too many bytes.
I also assume it should read buf.read(bytes) and return bytes.

It is also needed to determine the semantics we want for the byte
buffers compared to the old byte[], is it the backing array's content
or the content between position
and limit()?

If position is taken into account, the above method is not idempotent,
two calls won't return the same array content as the call to get moves
the position.

Mathias.