decoding JsonTypeInfo on StoragePluginConfig

[Daniel Barclay <db...@maprtech.com>]

What exactly does the following Jackson @JsonTypeInfo annotation on
org.apache.drill.common.logical.StoragePluginConfig do?:


   @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property="type")
   public abstract class StoragePluginConfig {


Also, would that annotation still have the desired effect if
StoragePluginConfig were an interface?


Daniel
-- 
Daniel Barclay
MapR Technologies

Re: decoding JsonTypeInfo on StoragePluginConfig

[Daniel Barclay <db...@maprtech.com>]

Jacques,

Jacques Nadeau wrote:
> See here:
>
> http://fasterxml.github.io/jackson-annotations/javadoc/2.4/com/fasterxml/jackson/annotation/JsonTypeInfo.html
>
> Basically, this states that when encoding/decoding from JSON, the "type"
> field

There you're referring to the field in JSON, right?

> is used to determine which subclass of StoragePluginConfig should be
> materialized.  It also says to store the "type" field as a property
 > inside the object to be serialized/deserialized.

To clarify that:  You mean Jackson stores it just in the JSON and not that
Jackson stores in any Java property in a StoragePluginConfig subclass
instance, right?

Do type values for the type property come from only the @JsonTypeName
annotation on a subclass (when present) or the subclass's simple name
(when @JsonTypeName is not present)?  (Does Jackson (directly) access any
of the "name" or "NAME" members in our various subclasses of
StoragePluginConfig?)


Daniel
-- 
Daniel Barclay
MapR Technologies

Re: decoding JsonTypeInfo on StoragePluginConfig

[Parth Chandra <pa...@apache.org>]

I'm with Jacques on this one. The move from Hadoop 1 to Hadoop 2 was a big
issue.
I would would be in favor of not changing abstract classes to interfaces
unless things are broken.


On Mon, Jul 13, 2015 at 5:26 PM, Daniel Barclay <db...@maprtech.com>
wrote:

> Jacques Nadeau wrote:
>
>> ...
>>
>> (As a side commentary, my sense is that people have started moving away
>> from interfaces in java and towards abstract classes since enhancements
>> can
>> be given default implementations rather than breaking downstream projects.
>> We saw this extensively in the move from Hadoop 1 to Hadoop 2.  As such, I
>> think we should be cautious about when and if we use interfaces.)
>>
>
> That can be addressed by declaring methods in an interface and providing a
> corresponding class with the default implementations.  (Client code that
> wants to just keep working can extend the class, but code that wants or
> needs an interface (e.g., dynamic proxy classes) still has one.)
>
> Note that in Java 1.8, interfaces can provide default implementations of
> methods, allowing compatibility while avoiding the limitations of using
> a class.
>
>
> Daniel
> --
> Daniel Barclay
> MapR Technologies
>

Re: decoding JsonTypeInfo on StoragePluginConfig

[Daniel Barclay <db...@maprtech.com>]

Jacques Nadeau wrote:
> ...
>
> (As a side commentary, my sense is that people have started moving away
> from interfaces in java and towards abstract classes since enhancements can
> be given default implementations rather than breaking downstream projects.
> We saw this extensively in the move from Hadoop 1 to Hadoop 2.  As such, I
> think we should be cautious about when and if we use interfaces.)

That can be addressed by declaring methods in an interface and providing a
corresponding class with the default implementations.  (Client code that
wants to just keep working can extend the class, but code that wants or
needs an interface (e.g., dynamic proxy classes) still has one.)

Note that in Java 1.8, interfaces can provide default implementations of
methods, allowing compatibility while avoiding the limitations of using
a class.

Daniel
-- 
Daniel Barclay
MapR Technologies

Re: decoding JsonTypeInfo on StoragePluginConfig

[Jacques Nadeau <ja...@apache.org>]

See here:

http://fasterxml.github.io/jackson-annotations/javadoc/2.4/com/fasterxml/jackson/annotation/JsonTypeInfo.html

Basically, this states that when encoding/decoding from JSON, the "type"
field is used to determine which subclass of StoragePluginConfig should be
materialized.  It also says to store the "type" field as a property inside
the object to be serialized/deserialized.  (Note, another option is to hold
this in a separate container as a WRAPPER_OBJECT).

Interface: probably(?)

Initially there were certain bugs inside of Jackson that caused issues when
using interfaces for certain things.

(As a side commentary, my sense is that people have started moving away
from interfaces in java and towards abstract classes since enhancements can
be given default implementations rather than breaking downstream projects.
We saw this extensively in the move from Hadoop 1 to Hadoop 2.  As such, I
think we should be cautious about when and if we use interfaces.)

On Mon, Jul 13, 2015 at 11:33 AM, Daniel Barclay <db...@maprtech.com>
wrote:

> What exactly does the following Jackson @JsonTypeInfo annotation on
> org.apache.drill.common.logical.StoragePluginConfig do?:
>
>
>   @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include =
> JsonTypeInfo.As.PROPERTY, property="type")
>   public abstract class StoragePluginConfig {
>
>
> Also, would that annotation still have the desired effect if
> StoragePluginConfig were an interface?
>
>
> Daniel
> --
> Daniel Barclay
> MapR Technologies
>