users@jsonb-spec.java.net

[jsonb-spec users] [jsr367-experts] Re: Re: Re: [1-RuntimeAPI] Proposal

From: Martin Grebac <martin.grebac_at_oracle.com>
Date: Tue, 24 Feb 2015 15:38:55 +0100

On 24.02.15 1:22, Inderjeet Singh wrote:
> Classes makes for a better extensible API than Interfaces.
> This is especially true for the classes that a user/developer will
> need to implement.
>
> We made this mistake in Gson, JsonSerializer/JsonDeserializer were
> Interfaces. So it is impossible to extend them.
> For Gson TypeAdapter, we chose an abstract class which allows us to
> extend it whenever we want.
>
> Inder
Since default methods in interfaces I don't consider this an argument
for abstract classes.
  MartiNG

> On Mon, Feb 23, 2015 at 8:13 AM, Martin Grebac
> <martin.grebac_at_oracle.com <mailto:martin.grebac_at_oracle.com>> wrote:
>
> On 20.02.15 11:10, Hendrik Dev wrote:
>
> On Fri, Feb 20, 2015 at 10:43 AM, Przemyslaw Bielicki
> <pbielicki_at_gmail.com <mailto:pbielicki_at_gmail.com>> wrote:
>
> @Hendrik - no I was serious about system / environment
> properties because
> this is a common way of overriding compiled
> properties/settings in different
> test and (pre)production environments. I also proposed a
> specialized
> JsonbConfig interface which is more generic approach, thus
> system properties
> can be considered as a dead-issue (or trolling if you
> prefer ;)
>
> I clearly prefer the "specialized JsonbConfig" approach, not a
> big fan
> of system props to be honest.
>
> As I said before - I'm a supporter or the opinion that API
> should contain
> only interfaces and exception classes. I'm open for some
> extremely useful
> exceptions to this rule but all the ppl here should be
> aware that changing
> something in RI will be quick and easy while if we make
> mistake or want to
> change anything in the API classes it might take months
> (even for simple
> change) because of JCP process.
>
> agree
>
> I think you should post your diffs as email attachment. I
> prefer github but
> as I understand we are not going to use it for this
> project, so we have to
> get used to pure git.
>
> Patches attached
>
> Thanks, all applied.
> MartiNG
>
>

-- 
Martin Grebac, SW Engineering Manager
Oracle Czech, Prague