Mihai, I never heared of a standard that forbirds products to have additional features as long as those are not conflicting. I completely cannot see the point you make with monster applications. For example in JPA you can use the standardized API to pass native hints, which e. g. enable proprietary performance improvements. This code still runs well on any JPA implementation and nothing is vendor-locked or "monster". Following your idea would remove query hints from that API, leading to exactly the same code minus one line, but just running way slower in production. Nobody would have a benefit of such a restriction. -Markus From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Mihai A.
Sent: Dienstag, 11. September 2018 21:36
To: Jakarta EE community discussions
Subject: 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
|
