Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Eclipse Jetty and EE4J

Hi,

There were no closed source RIs for ages. The only exception was Java ME over the last decade or more.

More inline.


Werner



On Sun, Oct 15, 2017 at 10:34 AM, <ee4j-community-request@xxxxxxxxxxx> wrote:
Send ee4j-community mailing list submissions to
        ee4j-community@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://dev.eclipse.org/mailman/listinfo/ee4j-community
or, via email, send a message with subject or body 'help' to
        ee4j-community-request@eclipse.org

You can reach the person managing the list at
        ee4j-community-owner@eclipse.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."


Today's Topics:

   1. Re: Tomitribe commitment to EE4J (Guillermo Gonz?lez de Ag?ero)
   2. Re: Eclipse Jetty and EE4J (Guillermo Gonz?lez de Ag?ero)


------------------------------

Message: 2
Date: Sun, 15 Oct 2017 08:34:30 +0000
From: Guillermo Gonz?lez de Ag?ero      <z06.guillermo@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Eclipse Jetty and EE4J
Message-ID:
        <CAG1ZpUYahFb7ki6ppm8pNktbBCj8QTtWQFjGO+Q5omfyQmM60A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I think we're all basically saying the same. "No RI" seems equivalent "at
least one, but not limited to, one RI".

Nobody wants a finished spec without a complaint implementation. The idea
of the single RI made sense with a somewhat private process and closed
source RIs where maybe even some EG members didn't have access to it. But a
truly open process means everyone has the same rights and has access from
minute 1 to everything.

I also expect to see more specifications being co-lead by multiple vendors,
which will presumably like to have each their own implementation marked as
the "Reference" implementation. The reference implementations for a spec
version could be defined at the beginning and then the spec would be
finished when the RIs are done.


So far there is only one JSR with at least 2 variants of the RI, JavaMoney/aka JSR 354. Unfortunately having just one Spec Lead (Credit Suisse) its internal struggles and organizational changes not only had its EC (alternate) reps come and go every few months. The inability to find an appropriate replacement for Anatole as Maintenance Lead has caused a stalemate for quite a while. Despite the community and users from Spring to Zalando or Red Hat (via BV/Hibernate Validator) eager to use and further improve it.

That is something the JCP is aware, but has not fully tackled such problems in JCP.next yet.

Having more than one RI may not be necessary, but having multiple Spec Leads usually helps prevent this or other slow-moving JSRs (e.g. 377 which also has only 1 Spec Lead so far)
 
More response inline.

El s?b., 14 oct. 2017 a las 23:45, Greg Wilkins (<gregw@xxxxxxxxxxx>)
escribi?:

>
>
> On 15 October 2017 at 08:13, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>
>> Hi,
>>
>
>> It's not the prettiest of examples, but we kinda did that with the JASPIC
>> 1.1 register session feature. It was unfortunately quite a bit
>> underspecified, so vendors basically had no clue how to implement it at all
>> and had to follow the way it was done in the RI.
>>
>
> Arjan,
>
> I think that example is indeed not pretty, but actually argues for why RIs
> facilitate lazy specifications.   If the process required several
> implementors to implement the draft and do interop testing before going
> final, than such poor specifications would be noticed earlier, without
> making one implementors version the defacto standard regardless of merit.
>
> Note also that most implementations continue to be developed after the
> specification is pronounced final, and who is to say that an RIs
> subsequent development direction actually expresses the intent of the
> expert group?  If difficult problems are subsequently discovered, surely
> they should be taken back to the expert group for resolution rather than be
> left in the hands of one specially anointed implementation?
>
>
>
>> It's also an important requirement; the spec can not be released without
>> an implementation proving it's at least possible to implement.
>>
>>
> Absolutely working code should be required.  But I'm suggesting that a
> sample of 1 is not sufficient to test a spec and that the process should
> encourage multiple implementations during the draft stage.   In fact having
> an implementation that substantially passes the draft TCK may be a good
> qualifier to give voting rights for deciding if the spec is ready to go
> final!
>
> So perhaps we should think of the process allowing multiple RIs rather
> than none?    More over, perhaps it is specific versions of those
> implementations that should be noted as being reference implementation at
> the time the spec goes final.
>
It's interesting to me that certified Java EE servers are only tested for
one version on some specific environments (
http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html).
That means GlassFish 4.0 is Java EE 7 compatible, what we know nothing
about GlassFish 4.1.

I support your idea of specific versions being considered the RI, but open
TCKs will make it easy for users to test themselves. Probably most vendors
will even run TCK tests as part of their CI pipelines, making the RI
"upgradeable".


We've been doing this with different implementations of JSR 363 including its RI:

At least 2 other compatible implementations (one at Eclipse, one at Apache) are being added soon, can't say, if Apache SIS will also run a CI test against the TCK, but it is known to pass the TCK already.


 
Anyway it's definitely an interesting thought.

>
> cheers
>
>
> --
> Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j-community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171015/2dfa648c/attachment.html>

------------------------------

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community


End of ee4j-community Digest, Vol 2, Issue 121
**********************************************


Back to the top