users@jsonb-spec.java.net

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

From: Oleg Tsal-Tsalko <oleg.tsalko_at_gmail.com>
Date: Tue, 24 Feb 2015 12:09:12 +0200

Hi guys,

With Java 8 default methods there is no much need in abstract classes with
only exception if you have default implementation for almost all business
methods and leave only couple of methods to be implemented by child classes
I would say.
Also with interfaces centric approach we can even use @FunctionalInterfaces
where appropriate to be more lambdas friendly.
One of the examples is JsonbProvider which could be @FunctionalInterface
actually if it's only responsibility to supply specific JsonbBuilder
instance.
On diff discussion thread I heard rumors that spec is not targeted for Java
8. I hope it's not true, is it?
Even in pom.xm file we have:
<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

<version>3.1</version>

<configuration>

<source>1.8</source>

<target>1.8</target>

<compilerArgument>-Xlint:all</compilerArgument>

</configuration>

</plugin>

Thank you,
Oleg

2015-02-24 2:22 GMT+02:00 Inderjeet Singh <inder_at_alumni.stanford.edu>:

> 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
>
>
>
>
> On Mon, Feb 23, 2015 at 8:13 AM, Martin Grebac <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> 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
>>
>>
>