Hi Martin, Hi Experts,
sorry for delay, here are my comments and patches:
1) Do we really need a JSONB_FROMJSON_ENCODING and if yes whats the
default? According to RFC 4627 JSON is must always be Unicode and the
encosing can therefore be always be detected by the algo described in
chapter 3.
2) Jsonb.java: Do we also want to add java.nio andy byte[] support here?
3) Jsonb.java: Suggest to change Class<T> to Type for the fromJson()
methods to support generic types. (JSONB_SPEC-30)
4) @Przemyslaw: System properties? later you said trolling, hope so :-)
5) Interface approach: Id like to see interfaces (over classes) since
implementations have to also "implement" the spec jars (depending on
licesing stuff), so its not helpful here to try to solve things in the
spec jars once and forever. It makes it even harder because if to much
code and classes are in the spec the distinction between spec and impl
will get vague and spec gets bloated (if you're looking for a good
example see javamail/JSR-919).
6) Patches:
https://github.com/salyh/spec/commits/salyh_fixes1 (or
maybe better attach it to the mail as .diff?)
General:
I'd like to create a simple (but yet powerful) api since JSON itself
is simple but powerful. So i agree not to rebuild JAXB for JSON cause
XML is not JSON.
As one who has implemented JSR 353 i am glad to see no factories in
the current runtime api proposal. I'd like the builder and immutable
approach cause with some sensitive default shortcuts. I aggree with
Inderjeet that Jsonb() should be sufficient the most use cases. I do
NOT aggree with Inderjeet when he says
"There is typically NO developer concern about plugging in an
alternate implementation. So, we should just have a really good
default implementation and get rid of providers."
cause thats a) not true and b) if you mean with default implementation
the RI then this is also not true. RI has IMHO a total other emphasis
than other non-RI implementations (and of course other licenses :-).
Inder, maybe you can clarify this, thanks :-)
BTW: Do i have missed the round of introductions?
Kind regards
Hendrik
On Tue, Feb 10, 2015 at 7:15 PM, Inderjeet Singh
<inder_at_alumni.stanford.edu> wrote:
> Hi Martin,
>
> I am not saying that builder shouldn't be available. I am saying that the
> default options should be so good that new Jsonb() should be sufficient in
> most cases. Builder should be left for customizations.
>
> JavaEE may be your goal, but JavaSE + Web stack is what is ruling the
> developer world today. For this JSR to be widely used, improving experience
> with Java SE should be the primary goal. For Java EE, provide some advanced
> provider API that most developers don't have to see.
> (I used to be a JavaEE guy too (at Sun), but never quite saw the providers
> being all that useful. How often have people in this group really needed to
> use the providers in JAXP?)
>
> Inder
>
>
>
> On Tue, Feb 10, 2015 at 9:11 AM, Martin Grebac <martin.grebac_at_oracle.com>
> wrote:
>>
>> Hi,
>> thanks, understood, though I'd consider Builder to not be a complicated
>> structure even for beginners. We'll get to the advanced usecases, I'll be
>> bringing up generic types discussion soon, I'm expecting lots of fun on this
>> topic ;O). I understand the point on providers, too, that goes more towards
>> Java SE world, where there's usually one implementation which rules it all.
>> Java EE world uses a different concept, where providers are (more or less)
>> needed, even though in the end it may turn out there is going to be just a
>> few real implementations.
>> MartiNG
>>
>>
>> On 06.02.15 18:30, Inderjeet Singh wrote:
>>>
>>> Hi Martin,
>>>
>>> 1. How about replacing Jsonb with Json everywhere in the API?
>>> Json is shorter and easier to understand. "b" doesn't
>>> necessarily make sense from a developer's perspective.
>>>
>>> I actually ran through several different iterations before:
>>> 'Json', 'Jsonb', 'JsonBind', 'JsonBinding'. Though, I found
>>> 'JsonBind' and 'JsonBinding' unnecessarily long, and simple 'Json'
>>> clashes with JSON-P. It is going to be a usual case to have JSON-P
>>> and JSON-B code to be mixed together in the same class/method so
>>> it will cause a lot of confusion.
>>>
>>>
>>> Ok. I wasn't actually aware of the JSON-P APIs. As a developer, I would
>>> expect the APIs to work seamlessly, so some mixing may actually be
>>> desirable.
>>>
>>> 2. JsonBuilder.create() and newBuilder() methods seem unnecessary to me.
>>>
>>> new JsonBuilder() has much less conceptual weight as everyone
>>> understand what "new" does.
>>> 3. I think we should get rid of Providers. They don't add any
>>> value from a developer's perspective. If you really want it,
>>> add an SPI.
>>>
>>> I think the 2 above are connected, though I'm not sure I'm able to
>>> create the full picture. Would you share more details on this?
>>>
>>>
>>> From my experience designing Gson API, I think the developers care about
>>> two things:
>>> 1. Instantiate and configure a Gson instance. Actually, I don't even like
>>> builders all that much.
>>> new Gson() provides all the sensible defaults and GsonBuilder is meant
>>> only for advanced customizations. In practice, we made a few mistakes in
>>> selecting defaults for Gson (incorrect default date format, permissible
>>> deserialization, etc.), so using the GsonBuilder is often necessary.
>>>
>>> Since JsonB API is starting from scratch, it should learn from our
>>> mistakes, and have a really good "new Jsonb()"implementation.
>>>
>>> 2. Use the Gson instance. Here the primary concern is ease-of-use
>>> (toJson/fromJson), and ability to handle advanced use-cases (generic types,
>>> type variables, collections, etc.). Additional concerns are runtime
>>> performance, and thread-safety.
>>>
>>> There is typically NO developer concern about plugging in an alternate
>>> implementation. So, we should just have a really good default implementation
>>> and get rid of providers.
>>>
>>> Inder
>>
>>
>
--
Hendrik Saly (salyh, hendrikdev22)
@hendrikdev22
PGP: 0x22D7F6EC