Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot add a custom writer for an interface #12

Closed
treeswift opened this issue Jul 7, 2014 · 4 comments
Closed

Cannot add a custom writer for an interface #12

treeswift opened this issue Jul 7, 2014 · 4 comments
Labels

Comments

@treeswift
Copy link

Use case:

  • field type is an interface type (e.g. CharSequence);
  • I don't want to preserve the concrete class of the value (it can be complicated and heavyweight, something like WordProcessorMainWindowSpan);
  • I inherit a custom writer from JsonStringWriter and write value.toString() as a primitive String;
  • I call addWriter(CharSequence.class, myCustomWriter).
    Expected:
  • value is serialized and retrieved as String;
    Actual:
  • writer is not recognized because no superclass matches CharSequence.

P.S. For interfaces, I'd also appreciate the ability to stick to a default implementation explicitly (i.e. override the concrete type upon deserialization - of course, within types assignable to the declared field type).

@jdereg
Copy link
Owner

jdereg commented Jul 8, 2014

I see a couple of issues with what is listed here. First, the field type
cannot be "morphed" unless you are using both a custom reader and a custom
writer. Are you doing that? If not, the reader will blow up when it
encounters the String and tries to 'set' it into the field of type
'WordProcessorMainWindowSpan'.

Second, overriding CharSequence is asking for trouble, as that would also
override String, for which is handled specially by json-io. Was
CharSequence just an example? If so, could you provide a different
example? I am still not sure I understand what exactly is the issue.

On Mon, Jul 7, 2014 at 6:20 PM, LXE notifications@github.com wrote:

Use case:

  • field type is an interface type (e.g. CharSequence);
  • I don't want to preserve the concrete class of the value (it can be
    complicated and heavyweight, something like WordProcessorMainWindowSpan);
  • I inherit a custom writer from JsonStringWriter and write
    value.toString() as a primitive String;
  • I call addWriter(CharSequence.class, myCustomWriter). Expected:
  • value is serialized and retrieved as String; Actual:
  • writer is not recognized because no superclass matches CharSequence.

P.S. For interfaces, I'd also appreciate the ability to stick to a default
implementation explicitly (i.e. override the concrete type upon
deserialization - of course, within types assignable to the declared field
type).


Reply to this email directly or view it on GitHub
#12.

@treeswift
Copy link
Author

  • Yes, I am using a custom reader and a custom writer. (Or at least "I can do it if I have to".)
  • No, I do not want to "morph" the field type. I want to "morph" the concrete value type. Have you got the difference?
  • Overriding CharSequence will not override String because of getDistance(classA, classB). Distance between String and String is zero, so the default reader/writer would be used for the concrete type String.
  • I think my example explains the issue well enough. I will stick to it.

@treeswift
Copy link
Author

To summarize, if the object graph is

class POJO {
    CharSequence data;
}

I want to ensure the following postcondition:

((POJO) JsonReader.jsonToJava(whatever)).data instanceof String

no matter what the concrete type of data was before calling javaToJson(originalPojo).

@treeswift
Copy link
Author

So far I went without it by doing the conversion (.toString()) in the field setter - but that's not as efficient as it could be (the setter could have been called many times before the actual serialization).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants