[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] JAX-RS 2.1.1 Available On Maven Central
|
Well, yes, that's the point of a Specification, right? Having different implementations with the same interfaces. Functionality wise they should all be the same, but maybe some have less bugs, are faster than others etc.
It's a difficult discussion, of course, but it seems to me letting each vendor add its stuff only leads to monster applications which can only run on platform X, because nobody can figure out the mess in the pom.xml or understand what that dubious deployment descriptor is actually doing.
Sure, there are ways to do it in a clean manner and maintain portability (more or less) but very few people understand how to do that :D
Arjan did a nice job of explaining the
first question in Mihai's post, I'll try the second question...
> On Tue, Sep 11, 2018 at 8:31 PM Mihai A. <amihaiemil@xxxxxxxxx>
wrote:
>
> I would like EF to not make the same mistake Oracle did, and that
is
> allow vendors to implement more than the spec covers. Because it's
> in the best interest of vendors to tie developers to their own
> (licenced, paid) implementations. They do this by adding new,
> proprietary, features. Devs do not realize this, of course, until
> their code is in Production :)
>
Really? You want no value-add
capabilities provided by vendors? You want the exact same implementation
by all vendors? So, basically, you are asking for a Reference Implementation
and no more? Actually, you aren't even asking for that since several
of the Reference Implementations provide more than the Spec provides (Mojarra
and Jersey are two such examples). Thus, not even Glassfish satisfies
your requirement.
But, I would argue that this is what
the Spec, API, and TCK are for. These three in combination define
a contract. As long as a developer only uses the features defined
by the Spec and API, then their application should be portable between
TCK-compliant implementations. Sure, there will be edge cases. But,
for the most part, that's how you ensure that your applications are portable.
Stick to the Spec and don't wander off into the vendor's weeds...
On the other hand, you may find several
nice features that your vendor is providing over and above the Spec. It
is your choice whether to utilize those features. But, then your
application portability may become more difficult.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
jakarta.ee-community-bounces@xxxxxxxxxxx wrote on
09/11/2018 02:03:24 PM:
> From: arjan tijms <arjan.tijms@xxxxxxxxx>
> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
> Date: 09/11/2018 02:03 PM
> Subject: Re: [jakarta.ee-community] JAX-RS 2.1.1
Available On Maven Central
> Sent by: jakarta.ee-community-bounces@xxxxxxxxxxx
>
> Hi,
> On Tue, Sep 11, 2018 at 8:31 PM Mihai A. <amihaiemil@xxxxxxxxx>
wrote:
> Sorry to intervene again, but it seems funny.
Why was this in
> discussion in the first place? What is the sense of a specification
> if not to lead the market?
>
> For me it was never really a discussion, and it was certainly not
> how we intended to run the JSF, _expression_ Language, EE Security,
> JACC, JASPIC, and Concurrency specs. The specification process is
> always a combination of coming up with new features, refining
> existing features, and standardising things that have been proven
to
> work and which many implementations already have in some shape or
> form. Typically if something has been implemented before in a
> proprietary way it will get accepted much faster, and something
> really experimental or unproven is not a prime candidate for adding
> to the spec.
>
> It differs a little between specs though. For instance, JPA has
> taken more features from implementations like Hibernate in its
> revisions. JSF has done less so, since Mojarra and MyFaces are first
> and foremost implementations of JSF and far less (or maybe not at
> all) an independent framework as well.
>
> Kind regards,
> Arjan
>
>
>
> I would like EF to not make the same mistake Oracle did, and that
is
> allow vendors to implement more than the spec covers. Because it's
> in the best interest of vendors to tie developers to their own
> (licenced, paid) implementations. They do this by adding new,
> proprietary, features. Devs do not realize this, of course, until
> their code is in Production :)
>
> On Tue, Sep 11, 2018, 20:53 Markus KARG <markus@xxxxxxxxxxxxxxx>
wrote:
> Mike,
>
> in fact you told me in person at ECE 2017 that
you do NOT want
> specifications to be developed first, and then added ontop of the
> products, but that you want the specifications to describe the
> EXISTING features of the existing products. I can't help it if you
> didn't want to say or imply that, but it was what I (and others in
> the room) understood. This might be a misunderstanding, so let's
> restart from scratch:
>
> So a specification project MAY invent new features
in the
> specifiation FIRST, before ANY product actually implements this?
> Good for us! :-)
>
> -Markus
>
> From: jakarta.ee-community-bounces@xxxxxxxxxxx
[mailto:jakarta.ee-
> community-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
> Sent: Dienstag, 11. September 2018 16:22
> To: jakarta.ee-community@xxxxxxxxxxx
> Subject: Re: [jakarta.ee-community] JAX-RS 2.1.1 Available On Maven
Central
>
> On 2018-09-09 7:18 AM, Markus KARG wrote:
> Unfortunately this is not the EFs official policy.
According to EF
> president Mike Milinkovic, all EE4J API projects shall NOT force
> features from vendors, but instead shall only wrap existing features
> under a common hood. What I did is adding feature to API AND to
> Jersey parallel, and encouraged other vendors to follow.
>
> Markus,
>
> I don't recall ever making the statement above. It's possible that
> there's been a misunderstanding.
>
> I do expect innovation to happen in the specifications once we get
> the process going. There will have to be some give-and-take between
> the aspirations of the community and the vendors who have to bear
> the cost of implementing them. But I see that as a normal part of
> any specification process that desires to deliver new innovations.
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://urldefense.proofpoint.com/v2/url?
> u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=qRLu4PpskR6nCETWmPMeorQ2XwFTOWFyFK08bsE5Rf4&s=xZhB6TuOmo1s91w4MejfoBl3HlYB9hwhbTR4qCTsG9U&e=
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
