Andrew Guibert

I agree that some sort of `@Impl` annotation on the field/method defeats the purpose of the application using an interface to begin with. The main thing I'm after is type-safety...

> Woudlnt it be broken in array of object case? Not sure what you are referring to here -- can you clarify what you mean by this? > What about...

@struberg can you elaborate on how you thin this should work? For example, how would JSON-B know that `"marriedTo":"/"` is a JSON Pointer and not a String value of `/`?...

I think it's important to consider interop with other languages and libraries besides just JSON-B here. While Johnzon may be able to understand JSON like this: ```json { "name":"John", "marriedTo":...

since there is no clear standard solution to this in the JavaScript community, I'm inclined to just cancel this issue until the JS community standardizes a solution around this (if...

@m0mus is the JSON-B user guide available on github? If you can point me to it, I can take care of this issue.

Closing this as stale

IMO the spec is pretty clear already: ``` Deserialization of a JSON value into an enum instance MUST be done by calling the enum’s valueOf(String) method. ``` If we pass...

I suppose we could append the text: `If deserializing the enum fails, an error is raised.` @m0mus do you have an estimate of where the spec asciidoc is? It looks...

This is something we could consider for the next version of the spec. However, there are workarounds to this available with 1.0. Here are some examples of existing behavior... Default...