Skip to main content

[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


It may be simply that I am reading too much into your use of the word 'product'. When I hear 'product', I think proprietary-licensed intellectual property. Maybe you think of the word differently. My definition of code first includes community-led open source projects which are seeing adoption, even if they have not been productized by a vendor.

The spec process requirements did state that at least one open source implementation of a specification version must exist before the spec can be adopted. So I think we're in agreement on that point.

On 2018-09-11 4:43 PM, Markus KARG wrote:

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

 

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.


Back to the top