[
https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14267220#comment-14267220
]
Vitali Lovich edited comment on THRIFT-1854 at 1/7/15 3:04 AM:
---------------------------------------------------------------
Hey [~codesf]. I don't believe the recommended approach works, at least for
trove.
The trove interface is different from Java since it's dealing with unboxed
types. Iteration (for serialization) is different from regular Java
collections since none of those collections implement (nor can they) Iterable,
so they can't use regular for-loops.
Additionally, getting the key/value from an iterator is different for Trove -
it's .key()/.value() instead of .getKey()/.getValue().
Moreover, the suggested TFloatList wouldn't compile since a double cannot be
assigned to a float.
Finally, annotations are great for customization of individual fields.
However, it does make sense to have command-line switches so that you can
specify a default implementation without needing to do custom overrides.
That being said, I think there does need to be a more generic mechanism to
support this kind of thing.
Something like:
{{
type "java" TroveDoubleList {
api = "gnu.trove.list.TDoubleList";
internal = "gnu.trove.list.array.TDoubleArrayList";
loopStart = "for (int i_$(iterator) = 0; i < $(container).size(); ++i)";
accessor = "$(container).getQuick(i_$(iterator))";
}
}}
Then you can add an annotation like:
{{
(java.type = TroveDoubleList)
}}
And a top-level annotation like:
{{
typedef list<double> TroveDoubleList;
}}
However, nothing like this exists & the actual implementation would be very
complicated
(would need to support templated types), so this feels OK as a compile-time
switch for now.
was (Author: vlovich):
Hey [~codesf]. I don't believe the recommended approach works, at least for
trove.
The trove interface is different from Java since it's dealing with unboxed
types. Iteration (for serialization) is different from regular Java
collections since none of those collections implement (nor can they) Iterable,
so they can't use regular for-loops.
Additionally, getting the key/value from an iterator is different for Trove -
it's .key()/.value() instead of .getKey()/.getValue().
Moreover, the suggested TFloatList wouldn't compile since a double cannot be
assigned to a float.
Finally, annotations are great for customization of individual fields.
However, it does make sense to have command-line switches so that you can
specify a default implementation without needing to do custom overrides.
That being said, I think there does need to be a more generic mechanism to
support this kind of thing.
Something like:
type "java" TroveDoubleList {
api = "gnu.trove.list.TDoubleList";
internal = "gnu.trove.list.array.TDoubleArrayList";
loopStart = "for (int i_$(iterator) = 0; i < $(container).size(); ++i)";
accessor = "$(container).getQuick(i_$(iterator))";
}
Then you can add an annotation like:
(java.type = TroveDoubleList)
However, nothing like this exists, so this feels OK as a compile-time switch.
> trove support for lists of primitives
> -------------------------------------
>
> Key: THRIFT-1854
> URL: https://issues.apache.org/jira/browse/THRIFT-1854
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Compiler
> Reporter: Vitali Lovich
> Attachments:
> 0001-Add-support-for-trove-option-to-Java-generator.patch,
> 0002-adding-support-to-use-Trove-lists-instead-of-native-.patch,
> 0003-Implement-trove-support-for-sets.patch,
> 0004-Implement-trove-support-for-maps.patch
>
>
> When dealing with large collections of primitive types, there can be
> significant memory (i.e. using arrays of objects instead of arrays of
> primitives) & runtime overhead (autoboxing/unboxing) using the default
> collections. Utilizing trove can significantly improve things. ideally
> support would be added for sets & maps, but as a first pass lists would be
> great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
