[
https://issues.apache.org/jira/browse/THRIFT-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904277#action_12904277
]
Dave Engberg commented on THRIFT-872:
-------------------------------------
That would result in a fair amount of extra data copying. For example, the
TBinaryProtocol.readBinary() method currently does this:
public ByteBuffer readBinary() throws TException {
int size = readI32();
checkReadLength(size);
if (trans_.getBytesRemainingInBuffer() >= size) {
ByteBuffer bb = ByteBuffer.wrap(trans_.getBuffer(),
trans_.getBufferPosition(), size);
trans_.consumeBuffer(size);
return bb;
}
byte[] buf = new byte[size];
trans_.readAll(buf, 0, size);
return ByteBuffer.wrap(buf);
}
So if you really just want to get a byte[] array out of the TProtocol object,
you'd be creating the appropriate byte array once within readBinary(), then
wrapping that up in a new ByteBuffer instance only to immediately create a
duplicate byte[] and copying the data out. I'd be more inclined to go the
other way, and have the default (non-abstract) readBinary() implementation
invoke the byte[] version, since it can use the results without duplication.
I'd originally considered doing so, but didn't want to step on toes, so left
them separate.
Sorry about the tabs ... my emacs modes have gotten screwed up in the months
since the last time I touched C/C++ (i.e. the last time I did some stuff with
Thrift). I can submit a replacement patch whenever other issues are
consolidated.
> 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.
