[
https://issues.apache.org/jira/browse/THRIFT-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904344#action_12904344
]
Bryan Duxbury commented on THRIFT-872:
--------------------------------------
bq. That would result in a fair amount of extra data copying.
I think that actually might not be true. If you're using a direct buffer access
transport (Framed or MemoryInput, for instance), then the copy into the byte[]
in readBinary() would actually be the first copy. Further, if the direct access
path *isn't* taken, then the ByteBuffer you get back will necessarily be the
exact size you want, so you should be able to just return readBinary().array().
Your patch has the THRIFT-877 changes in it still. Do an svn up.
How about we avoid the if in the equals/compareto areas by just having
TBaseHelper called always? We can add a compareTo(ByteBuffer, ByteBuffer) that
lets us call the same method regardless.
I don't think that we should completely get rid of the logging of errors if
we're in primitive style; how about we just write to System.err instead?
> 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-v2.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.
-
You can reply to this email to add a comment to the issue online.
