[
https://issues.apache.org/jira/browse/THRIFT-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14267090#comment-14267090
]
Randy Abernethy commented on THRIFT-1854:
-----------------------------------------
Hey [~roger.meier],
A little late in the game perhaps, but my preference for all language specific
type substitution would be to use IDL annotations (as CPP does for base types)
not compiler switches (as Java does now) and not custom IDL (as CPP does now
for collections). My bias is based on the following:
- consistency: annotations provide a single clean way to add language generator
specific instructions (IDL being reserved for pure cross language abstractions)
- flexibility: using annotations in IDL you can use different implementations
selectively (a compiler switch applies to the entire compiled IDL)
- open endedness: annotation types accept any string, allowing new
implementation types to be added without adding new IDL annotation definitions
or compiler switches
Presently we have custom IDL (e.g. 1: map cpp_type "std::unordered_map<string,
int16_t>" <string, i16>), command line switches (e.g. -gen
java:sorted_containers) and annotations (e.g. 1: i32 (cpp.type = "long")
counter) which is a bit confusing.
I would much rather see Thrift move to using annotations universally for
implementation specification:
{code:title=Annotations|borderStyle=solid}
struct anno {
1: i32 (cpp.type = "long") counter
2: list<double> (cpp.type = "std::vector<float>", java.type =
"gnu.trove.list.TFloatList") values
3: list<double> (cpp.type = "std::vector<double>", java.type =
"gnu.trove.list.TFloatList") values
} (final="true")
{code}
The annotation parser already supports the above syntax.
Thoughts?
-Randy
> 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-adding-support-to-use-Trove-0.9-lists-for-lists.patch,
> 0001-adding-support-to-use-Trove-0.9.2-lists-for-lists.patch,
> 0001-adding-support-to-use-Trove-0.9.2-lists-for-lists.patch,
> 0001-adding-support-to-use-Trove-lists-for-lists.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)
