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
There are often products or projects that inspired or shaped standards.  Mike probably knows best himself, because at the time I heard he also was still closer to the code when TopLink and Hibernate both played important roles in shaping JPA.

Others like Batch got largely inspired by Spring Batch. The Unit standard took a while, but there 3 generations of "code first" projects paved the ground from UCAR Units to JScience and Uom.org (also implemented at Eclipse, an Independent Implementation of JSR 363 also done there) 

JCache is an example where the standard can only be seen as the  the smallest common denominator. And plenty of vendors first and foremost Hazelcast who drove the standard benefit from different proprietary features of various products. They (at least Red Hat, IBM and then driving company behind JCache Software AG) could not agree on a new standard that may have worked like CDI does on top of JSR 330, so 347 failed and had to be withdrawn.

With all due respect for what Ivar and others took over from Oracle it remains to be seen, if JSR 371 (MVC) ever gets adopted by the de-facto-standard in this space Spring MVC, well maybe once at Jakarta EE Spring 10 or 12 might do...?

There are plenty of examples outside the Jakarta and Java EE space, Eclipse IDE probably one of the most widely adopted.
Numerous desktop apps from minimalist Lotus/IBM SameTime (just a few MB) to gigantic near TB size products like Rational Architect and many others which extend the core with tons of features only found there.

Werner

On Tue, Sep 11, 2018 at 11:40 PM Mihai A. <amihaiemil@xxxxxxxxx> wrote:
Markus, this is why I said it's a long discussion. I think the Spec should be the Market's dictator but, on the other hand, the implementations should be extensible. This is not possible in the JavaEE world, though, since everything is based on annotations which are not extensible. Instead, Spec should be based on Java Interfaces, which can be decorated, their behaviour can very well be altered to fit particulat needs and tweaks.

About "monsters" I meant exactly this: a lot of developers have no idea what is Spec and what is Proprietary, since it is all so tangled. I met really experienced developers, good at what they do, but who did not know what the JDK is, let alone explain the word "platform" from "JavaEE platform".

Again, this is a difficult and most probably old discussion, which I think would be clarified if Spec would be the leader somehow :)

On Tue, Sep 11, 2018, 23:43 Markus KARG <markus@xxxxxxxxxxxxxxx> 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.

 




_______________________________________________
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

 

--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223

_______________________________________________
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

Back to the top