Mike,
yes I am pretty sure it is a misunderstanding so I kindly ask for some more clarification.
What kind of code do you have in mind when saying "code first" other than an existing a product, when at the same time you write "Personally I think that specifying something before (a) it has been implemented and (b) the market has demonstrated an interest in it, is unlikely to succeed."? Only a product which is already implemented and publicly available is able to fulfil (a) and (b). Can you please make an example of what kind of artifacts type we talk about here?
This does not imply the smallest common denominator of ALL existing products. It just means that SOME (at least one) product already must have such a feature before it is added to the spec.
-Markus
From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
Sent: Dienstag, 11. September 2018 21:53
To: jakarta.ee-community@xxxxxxxxxxx
Subject: Re: [jakarta.ee-community] JAX-RS 2.1.1 Available On Maven Central
This is just a misunderstanding.
I have said many times that we want Jakarta EE to have more of a "code first" approach to innovation, rather than the old JCP approach of "spec first". (Interestingly, the JCP is simultaneously evolving to a similar model so that it can better serve the needs of OpenJDK.)
I never meant to imply that future specs would simply be the lower common denominator of vendor's products. What I meant was that as an open source community we should try out experiments in code, and then specify when we have some reason to believe that the code is useful. I think we can all think of EE specifications in the distant past that could have benefited from such an approach.
Most of this "code first" thinking was about new specs. How existing specs are evolved up to the spec projects themselves. Personally I think that specifying something before (a) it has been implemented and (b) the market has demonstrated an interest in it, is unlikely to succeed. But this class of concerns can be addressed by tight iterative development of the spec, TCKs and one or more open source implementations.
None of this is meant to imply a free-for-all. Writing a spec that the vendors won't implement is useless. But so is writing a new version of an existing spec with zero useful innovations. That dynamic drives the difficult negotiations necessary in any spec process --- arriving at the correct balance between great ideas and what can realistically be implemented.
HTH
On 2018-09-11 1:53 PM, Markus KARG 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
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
