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
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.
