jsr367-experts@jsonb-spec.java.net

[jsr367-experts] Re: [1-RuntimeAPI] Proposal

From: Martin Grebac <martin.grebac_at_oracle.com>
Date: Fri, 06 Feb 2015 12:14:38 +0100

Hi, sorry, took some time to respond.

All, I submitted another iteration, trying to incorporate most of the
comments I received so far, Inderjeet's last comments were coming on
this version already I assume. There were many changes in between the
iterations, they are described partially in the commit logs and visible
in the code so not going to described them here. Either pull the latest
from runtime_api_init branch, or if you don't have it yet:

  git clone git://java.net/jsonb-spec~git (read-only)
  git clone ssh://<user_name>@git.java.net/jsonb-spec~git or
  cd jsonb
  git checkout runtime_api_init

For some other comments please see below ...

On 02.02.15 17:20, Eugen Cepoi wrote:
>
>
> createContext(final Class<?> ... classes) => Does that mean
> that the user will have to explicitly specify what will be the
> root classes being ser/de?? If yes, it looks too restrictive
> and how will this integrate with Jersey (JsonRootElement... :( )?
>
> I'd like to hear more opinions here, the question here is whether
> the usecase is strong enough such that it is not going to be too
> big requirement for all binding implementations to support it.
> Also, in javadoc the api allows empty set.
>
>
> It is not hard to impl., my concern is about making some rare use case
> the default, most people just want to ser/de what they pass in -
> versus explicitly tell what will be the classes being ser/de. I
> understand this feature as: if a class is not in this list and people
> try to ser it then an exception is thrown.
I think that is correct and it is reflected in the latest iteration. My
main aim there was leading towards a scope, and that is a separate
discussion and there are better ways to deal with it.

> Missing unmarshal/marshal methods taking input/outputstream
> and bytes.
>
> Intentionally left out, the reason is similar to the above, to
> evaluate whether streams are really needed once there are
> readers/writers and JSON being inherently a UTF text source/output
> so one does not have to deal with encodings. I recall I've also
> seen binding implementations which left io streams out.
> So, is there really a strong need to keep streams?
>
>
> In genson I left it out and then added it as I figured that people
> tended to copy the inputstream to a string and then pass the
> string...instead of just wrapping it in a reader. But it is more of a
> remark that it could be nice to have, especially if we already have File.
io stream methods have been added

> *Overall impression*
>
> - Is sticking to JAXB design a goal of this jsr? I would
> prefer not...**some parts look to me over complicated for no
> apparent reason.
>
> If there is a specific reason to deviate, we can do so, but
> keeping the apis with similar feel has its benefits in adoption
> and lower learning curve for all those already aware of JAXB api.
>
> What about the existing json libs API? Don't you think they differ
> from JAXB, but they all have a similar API and people are used with
> them when working with json? We want to provide an api for json users
> not JAXB users.
Fair point.

> - I was expecting to see jsonp reader/writers instead of std
> java io classes in Un/Marhsaller.
>
> Left out for now.
>
> I know you mentioned it but I wonder how do you see this integration
> with jsonp? I was thinking that JSONB would be a layer over JSONP,
> thus using it for all the low level io stuff - like what we see in
> json libs with the streaming layer vs the databinding one.
I'd see this as adding additional Jsonb from/to methods which would
allow dealing with Jsonp objects. I don't think we should limit JSON
Binding to support only JSON-P though.

> About JsonbContext, what is its goal and responsibility? The above
> example is also a suggestion on having Jsonb as a single entry point
> (and dropping JsonbContext), the shortcut static methods become object
> methods and the Builder configures Jsonb and the Un/Marshaller.
> Jsonb and all the other components become immutable.
>
> Would be again interesting to see other opinions :)
Absolutely!

As for other your comments, I'd say most have been addressed and would
recommend to have a look at the 2nd iteration.

Thanks,
  MartiNG