Hey,
- did we consider to make the return type (ie, ArrayList, vs
LinkesList) configurable or encode it the serialized bytes?
Not sure about this one. Could you elaborate?
- atm the size of each element is encoded individually; did we consider
an optimization for fixed size elements (like Long) to avoid this overhead?
I cannot think of any clean way to do so. How would you see it?
Btw I resolved all your comments under PR
Best,
Daniyar Yeralin
> On May 24, 2019, at 12:01 AM, Matthias J. Sax <matth...@confluent.io> wrote:
>
> Thanks for the KIP. I also had a look into the PR and have two follow up
> question:
>
>
> - did we consider to make the return type (ie, ArrayList, vs
> LinkesList) configurable or encode it the serialized bytes?
>
> - atm the size of each element is encoded individually; did we consider
> an optimization for fixed size elements (like Long) to avoid this overhead?
>
>
>
> -Matthias
>
> On 5/15/19 6:05 PM, John Roesler wrote:
>> Sounds good!
>>
>> On Tue, May 14, 2019 at 9:21 AM Development <d...@yeralin.net> wrote:
>>>
>>> Hey,
>>>
>>> I think it the proposal is finalized, no one raised any concerns. Shall we
>>> call it for a [VOTE]?
>>>
>>> Best,
>>> Daniyar Yeralin
>>>
>>>> On May 10, 2019, at 10:17 AM, John Roesler <j...@confluent.io> wrote:
>>>>
>>>> Good observation, Daniyar.
>>>>
>>>> Maybe we should just not implement support for serdeFrom.
>>>>
>>>> We can always add it later, but I think you're right, we need some
>>>> kind of more sophisticated support, or at least a second argument for
>>>> the inner class.
>>>>
>>>> For now, it seems like most use cases would be satisfied without
>>>> serdeFrom(...List...)
>>>>
>>>> -John
>>>>
>>>> On Fri, May 10, 2019 at 8:57 AM Development <d...@yeralin.net> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I was trying to add some test cases for the list serde, and it led me to
>>>>> this class `org.apache.kafka.common.serialization.SerializationTest`. I
>>>>> saw that it relies on method
>>>>> `org.apache.kafka.common.serialization.serdeFrom(Class<T> type)`
>>>>>
>>>>> Now, I’m not sure how to adapt List<T> serde for this method, since it
>>>>> will be a “nested class”. What is the best approach in this case?
>>>>>
>>>>> I remember that in Jackson for example, one uses a TypeFactory, and
>>>>> constructs “collectionType” of two classes. For example,
>>>>> `constructCollectionType(List.class, String.class).getClass()`. I don’t
>>>>> think it applies here.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Best,
>>>>> Daniyar Yeralin
>>>>>
>>>>>> On May 9, 2019, at 2:10 PM, Development <d...@yeralin.net> wrote:
>>>>>>
>>>>>> Hey Sophie,
>>>>>>
>>>>>> Thank you for your input. I think I’d rather finish this KIP as is, and
>>>>>> then open a new one for the Collections (if everyone agrees). I don’t
>>>>>> want to extend the current KIP-466, since most of the work is already
>>>>>> done for it.
>>>>>>
>>>>>> Meanwhile, I’ll start adding some test cases for this new list serde
>>>>>> since this discussion seems to be approaching its logical end.
>>>>>>
>>>>>> Best,
>>>>>> Daniyar Yeralin
>>>>>>
>>>>>>> On May 9, 2019, at 1:35 PM, Sophie Blee-Goldman <sop...@confluent.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Good point about serdes for other Collections. On the one hand I'd guess
>>>>>>> that non-List Collections are probably relatively rare in practice (if
>>>>>>> anyone disagrees please correct me!) but on the other hand, a) even if
>>>>>>> just
>>>>>>> a small number of people benefit I think it's worth the extra effort
>>>>>>> and b)
>>>>>>> if we do end up needing/wanting them in the future it would save us a
>>>>>>> KIP
>>>>>>> to just add them now. Personally I feel it would make sense to expand
>>>>>>> the
>>>>>>> scope of this KIP a bit to include all Collections as a logical unit,
>>>>>>> but
>>>>>>> the ROI could be low..
>>>>>>>
>>>>>>> (I know of at least one instance in the unit tests where a Set serde
>>>>>>> could
>>>>>>> be useful, and there may be more)
>>>>>>>
>>>>>>> On Thu, May 9, 2019 at 7:27 AM Development <d...@yeralin.net> wrote:
>>>>>>>
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>> I don’t see any replies. Seems like this proposal can be finalized and
>>>>>>>> called for a vote?
>>>>>>>>
>>>>>>>> Also I’ve been thinking. Do we need more serdes for other Collections?
>>>>>>>> Like queue or set for example
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Daniyar Yeralin
>>>>>>>>
>>>>>>>>> On May 8, 2019, at 2:28 PM, John Roesler <j...@confluent.io> wrote:
>>>>>>>>>
>>>>>>>>> Hi Daniyar,
>>>>>>>>>
>>>>>>>>> No worries about the procedural stuff. Prior experience with KIPs is
>>>>>>>>> not required :)
>>>>>>>>>
>>>>>>>>> I was just trying to help you propose this stuff in a way that the
>>>>>>>>> others will find easy to review.
>>>>>>>>>
>>>>>>>>> Thanks for updating the KIP. Thanks to the others for helping out with
>>>>>>>>> the syntax.
>>>>>>>>>
>>>>>>>>> Given these updates, I'm curious if anyone else has feedback about
>>>>>>>>> this proposal. Personally, I think it sounds fine!
>>>>>>>>>
>>>>>>>>> -John
>>>>>>>>>
>>>>>>>>> On Wed, May 8, 2019 at 1:01 PM Development <d...@yeralin.net> wrote:
>>>>>>>>>>
>>>>>>>>>> Hey,
>>>>>>>>>>
>>>>>>>>>> That worked! I certainly lack Java generics knowledge. Thanks for the
>>>>>>>> snippet. I’ll update KIP again.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Daniyar Yeralin
>>>>>>>>>>
>>>>>>>>>>> On May 8, 2019, at 1:39 PM, Chris Egerton <chr...@confluent.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Daniyar,
>>>>>>>>>>>
>>>>>>>>>>> I think you may want to tweak your syntax a little:
>>>>>>>>>>>
>>>>>>>>>>> public static <T> Serde<List<T>> List(Serde<T> innerSerde) {
>>>>>>>>>>> return new ListSerde<T>(innerSerde);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Does that work?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Chris
>>>>>>>>>>>
>>>>>>>>>>> On Wed, May 8, 2019 at 10:29 AM Development <d...@yeralin.net
>>>>>>>>>>> <mailto:
>>>>>>>> d...@yeralin.net>> wrote:
>>>>>>>>>>> Hi John,
>>>>>>>>>>>
>>>>>>>>>>> I updated JIRA and KIP.
>>>>>>>>>>>
>>>>>>>>>>> I didn’t know about the process, and created PR before I knew about
>>>>>>>> KIPs :)
>>>>>>>>>>>
>>>>>>>>>>> As per static declaration, I don’t think Java allows that:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Daniyar Yeralin
>>>>>>>>>>>
>>>>>>>>>>>> On May 7, 2019, at 2:22 PM, John Roesler <j...@confluent.io
>>>>>>>>>>>> <mailto:
>>>>>>>> j...@confluent.io>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for that update. Do you mind making changes primarily on the
>>>>>>>>>>>> KIP document ? (
>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-466%3A+Add+support+for+List%3CT%3E+serialization+and+deserialization
>>>>>>>> <
>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-466%3A+Add+support+for+List%3CT%3E+serialization+and+deserialization
>>>>>>>>> )
>>>>>>>>>>>>
>>>>>>>>>>>> This is the design document that we have to agree on and vote for,
>>>>>>>>>>>> the
>>>>>>>>>>>> PR comes later. It can be nice to have an implementation to look
>>>>>>>>>>>> at,
>>>>>>>>>>>> but the KIP is the main artifact for this discussion.
>>>>>>>>>>>>
>>>>>>>>>>>> With this in mind, it will help get more reviewers to look at it if
>>>>>>>>>>>> you can tidy up the KIP document so that it stands on its own.
>>>>>>>>>>>> People
>>>>>>>>>>>> shouldn't have to look at any other document to understand the
>>>>>>>>>>>> motivation of the proposal, and they shouldn't have to look at a
>>>>>>>>>>>> PR to
>>>>>>>>>>>> see what the public API will look like. If it helps, you can take a
>>>>>>>>>>>> look at some other recent KIPs.
>>>>>>>>>>>>
>>>>>>>>>>>> Given that the list serde needs an inner serde, I agree you can't
>>>>>>>>>>>> have
>>>>>>>>>>>> a zero-argument static factory method for it, but it seems you
>>>>>>>>>>>> could
>>>>>>>>>>>> still have a static method:
>>>>>>>>>>>> `public static Serde<List<T>> List(Serde<T> innerSerde)`.
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 7, 2019 at 12:18 PM Development <d...@yeralin.net
>>>>>>>>>>>> <mailto:
>>>>>>>> d...@yeralin.net>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Absolutely agree. Already pushed another commit to remove
>>>>>>>>>>>>> comparator
>>>>>>>> argument: https://github.com/apache/kafka/pull/6592 <
>>>>>>>> https://github.com/apache/kafka/pull/6592> <
>>>>>>>> https://github.com/apache/kafka/pull/6592 <
>>>>>>>> https://github.com/apache/kafka/pull/6592>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you for your input John! I really appreciate it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What about this point I made:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Since type for List serde needs to be declared before hand, I
>>>>>>>> could not create a static method for List Serde under
>>>>>>>> org.apache.kafka.common.serialization.Serdes. I addressed it in the
>>>>>>>> KIP:
>>>>>>>>>>>>> P.S. Static method corresponding to ListSerde under
>>>>>>>> org.apache.kafka.common.serialization.Serdes (something like static
>>>>>>>> public
>>>>>>>> Serde<List<T>> List() {...}
>>>>>>>> inorg.apache.kafka.common.serialization.Serdes)
>>>>>>>> class cannot be added because type needs to be defined beforehand.
>>>>>>>> That's
>>>>>>>> why one needs to create List Serde in the following fashion:
>>>>>>>>>>>>> new Serdes.ListSerde<String>(Serdes.String(),
>>>>>>>> Comparator.comparing(String::length));
>>>>>>>>>>>>> (can possibly be simplified by declaring import static
>>>>>>>> org.apache.kafka.common.serialization.Serdes.ListSerde)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On May 7, 2019, at 11:50 AM, John Roesler <j...@confluent.io
>>>>>>>> <mailto:j...@confluent.io>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the reply Daniyar,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That makes much more sense! I thought I must be missing
>>>>>>>>>>>>>> something,
>>>>>>>> but I
>>>>>>>>>>>>>> couldn't for the life of me figure it out.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What do you think about just taking an argument, instead of for a
>>>>>>>>>>>>>> Comparator, for the Serde of the inner type? That way, the user
>>>>>>>>>>>>>> can
>>>>>>>> control
>>>>>>>>>>>>>> how exactly the inner data gets serialized, while also bounding
>>>>>>>>>>>>>> the
>>>>>>>> generic
>>>>>>>>>>>>>> parameter properly. As for the order, since the list is already
>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>> specific order, which the user themselves controls, it doesn't
>>>>>>>>>>>>>> seem
>>>>>>>>>>>>>> strictly necessary to offer an option to sort the data during
>>>>>>>> serialization.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> -John
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, May 6, 2019 at 8:47 PM Development <d...@yeralin.net
>>>>>>>> <mailto:d...@yeralin.net>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi John,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I’m really sorry for the confusion. I cloned that JIRA ticket
>>>>>>>>>>>>>>> from
>>>>>>>> an old
>>>>>>>>>>>>>>> one about introducing UUID Serde, and I guess was too hasty
>>>>>>>>>>>>>>> while
>>>>>>>> editing
>>>>>>>>>>>>>>> the copy to notice the mistake. Just edited the ticket. Sorry
>>>>>>>>>>>>>>> for
>>>>>>>> any
>>>>>>>>>>>>>>> inconvenience .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As per comparator, I agree. Let’s make user be responsible for
>>>>>>>>>>>>>>> implementing comparable interface. I was just thinking to make
>>>>>>>>>>>>>>> the
>>>>>>>> serde a
>>>>>>>>>>>>>>> little more flexible (i.e. let user decide in which order
>>>>>>>>>>>>>>> records
>>>>>>>> is going
>>>>>>>>>>>>>>> to be inserted into a change log topic).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>> Daniyar Yeralin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On May 6, 2019, at 5:37 PM, John Roesler <j...@confluent.io
>>>>>>>> <mailto:j...@confluent.io>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Daniyar,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for the proposal!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If I understand the point about the comparator, is it just to
>>>>>>>> capture the
>>>>>>>>>>>>>>>> generic type parameter? If so, then anything that implements a
>>>>>>>> known
>>>>>>>>>>>>>>>> interface would work just as well, right? I've been considering
>>>>>>>> adding
>>>>>>>>>>>>>>>> something like the Jackson TypeReference (or similar classes in
>>>>>>>> many
>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>> projects). Would this be a good time to do it?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note that it's not necessary to actually require that the
>>>>>>>> captured type
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> Comparable (as this proposal currently does), it's just a way
>>>>>>>>>>>>>>>> to
>>>>>>>> make
>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>> there is some method that makes use of the generic type
>>>>>>>> parameter, to
>>>>>>>>>>>>>>> force
>>>>>>>>>>>>>>>> the compiler to capture the type.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Just to make sure I understand the motivation... You expressed
>>>>>>>>>>>>>>>> a
>>>>>>>> desire
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> be able to serialize UUIDs, which I didn't follow, since there
>>>>>>>>>>>>>>>> is
>>>>>>>> a
>>>>>>>>>>>>>>>> built-in UUID serde:
>>>>>>>> org.apache.kafka.common.serialization.Serdes#UUID,
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> also, a UUID isn't a List. Did you mean that you need to use
>>>>>>>> *lists of*
>>>>>>>>>>>>>>>> UUIDs?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> -John
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, May 6, 2019 at 11:49 AM Development <d...@yeralin.net
>>>>>>>> <mailto:d...@yeralin.net>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Starting a discussion for KIP-466 adding support for List
>>>>>>>>>>>>>>>>> Serde.
>>>>>>>> PR is
>>>>>>>>>>>>>>>>> created under https://github.com/apache/kafka/pull/6592 <
>>>>>>>> https://github.com/apache/kafka/pull/6592> <
>>>>>>>>>>>>>>>>> https://github.com/apache/kafka/pull/6592 <
>>>>>>>> https://github.com/apache/kafka/pull/6592>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There are two topics I would like to discuss:
>>>>>>>>>>>>>>>>> 1. Since type for List serve needs to be declared before
>>>>>>>>>>>>>>>>> hand, I
>>>>>>>> could
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> create a static method for List Serde under
>>>>>>>>>>>>>>>>> org.apache.kafka.common.serialization.Serdes. I addressed it
>>>>>>>>>>>>>>>>> in
>>>>>>>> the KIP:
>>>>>>>>>>>>>>>>> P.S. Static method corresponding to ListSerde under
>>>>>>>>>>>>>>>>> org.apache.kafka.common.serialization.Serdes (something like
>>>>>>>> static
>>>>>>>>>>>>>>> public
>>>>>>>>>>>>>>>>> Serde<List<T>> List() {...}
>>>>>>>>>>>>>>> inorg.apache.kafka.common.serialization.Serdes)
>>>>>>>>>>>>>>>>> class cannot be added because type needs to be defined
>>>>>>>> beforehand.
>>>>>>>>>>>>>>> That's
>>>>>>>>>>>>>>>>> why one needs to create List Serde in the following fashion:
>>>>>>>>>>>>>>>>> new Serdes.ListSerde<String>(Serdes.String(),
>>>>>>>>>>>>>>>>> Comparator.comparing(String::length));
>>>>>>>>>>>>>>>>> (can possibly be simplified by declaring import static
>>>>>>>>>>>>>>>>> org.apache.kafka.common.serialization.Serdes.ListSerde)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2. @miguno Michael G. Noll <https://github.com/miguno <
>>>>>>>> https://github.com/miguno>> is questioning
>>>>>>>>>>>>>>>>> whether I need to pass a comparator to ListDeserializer. This
>>>>>>>> certainly
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> not required. Feel free to add your input:
>>>>>>>>>>>>>>>>> https://github.com/apache/kafka/pull/6592#discussion_r281152067
>>>>>>>> <https://github.com/apache/kafka/pull/6592#discussion_r281152067>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>> Daniyar Yeralin
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On May 6, 2019, at 11:59 AM, Daniyar Yeralin (JIRA) <
>>>>>>>> j...@apache.org <mailto:j...@apache.org>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Daniyar Yeralin created KAFKA-8326:
>>>>>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Summary: Add List<T> Serde
>>>>>>>>>>>>>>>>>> Key: KAFKA-8326
>>>>>>>>>>>>>>>>>> URL:
>>>>>>>> https://issues.apache.org/jira/browse/KAFKA-8326 <
>>>>>>>> https://issues.apache.org/jira/browse/KAFKA-8326>
>>>>>>>>>>>>>>>>>> Project: Kafka
>>>>>>>>>>>>>>>>>> Issue Type: Improvement
>>>>>>>>>>>>>>>>>> Components: clients, streams
>>>>>>>>>>>>>>>>>> Reporter: Daniyar Yeralin
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I propose adding serializers and deserializers for the
>>>>>>>> java.util.List
>>>>>>>>>>>>>>>>> class.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I have many use cases where I want to set the key of a Kafka
>>>>>>>> message to
>>>>>>>>>>>>>>>>> be a UUID. Currently, I need to turn UUIDs into strings or
>>>>>>>>>>>>>>>>> byte
>>>>>>>> arrays
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> use their associated Serdes, but it would be more convenient
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> serialize
>>>>>>>>>>>>>>>>> and deserialize UUIDs directly.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I believe there are many use cases where one would want to
>>>>>>>>>>>>>>>>>> have
>>>>>>>> a List
>>>>>>>>>>>>>>>>> serde. Ex. [
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>> https://stackoverflow.com/questions/41427174/aggregate-java-objects-in-a-list-with-kafka-streams-dsl-windows
>>>>>>>> <
>>>>>>>> https://stackoverflow.com/questions/41427174/aggregate-java-objects-in-a-list-with-kafka-streams-dsl-windows
>>>>>>>>>
>>>>>>>>>>>>>>> ],
>>>>>>>>>>>>>>>>> [
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>> https://stackoverflow.com/questions/46365884/issue-with-arraylist-serde-in-kafka-streams-api
>>>>>>>> <
>>>>>>>> https://stackoverflow.com/questions/46365884/issue-with-arraylist-serde-in-kafka-streams-api
>>>>>>>>>
>>>>>>>>>>>>>>>>> ]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> KIP Link: [
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-466%3A+Add+support+for+List%3CT%3E+serialization+and+deserialization
>>>>>>>> <
>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-466%3A+Add+support+for+List%3CT%3E+serialization+and+deserialization
>>>>>>>>>
>>>>>>>>>>>>>>>>> ]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> This message was sent by Atlassian JIRA
>>>>>>>>>>>>>>>>>> (v7.6.3#76005)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>
