Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Jakarta RPC Creation Review Comments...


I agree with your points here. I do not think we should say no to creating a specification because of technical concerns with the proposal. That is why we have a spec project to work through those. Plus this isn’t the old JCP where the lead holds the pen and has significant control over what goes into the spec, the goal here is to collaborate. I think Scott’s points are a good starting point for things to resolve as we move from proposal to specification.

I think the important thing is whether there is interest in having a specification here and the fact that multiple members have implemented gRPC of some flavour really suggests there is.


On Nov 25, 2021, at 7:03 AM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

My comment on this is not based on the technical merit of the details of this specification rather than on the process.
When faced with a creation review should we be looking at the technical details of what is proposed at this stage and whether it does or does not map to each vendor’s implementation?  Surely the question at this stage is whether there is sufficient interest in creating a specification project with broad product and community input that can create an api, specification and TCK. I would assume the purpose of any specification project development before ratification is to get to the point where the majority of these technical questions have been resolved.
If we insist on a fully formed api that has multi-party agreement at Creation Review then where does this work collaborative work occur? My assumption was that the purpose of a specification project was to do this work at the Eclipse Foundation. 
So my decision process in this is;
Are there multiple products trying to do this thing in their own way – yes in this case.
Would there be benefit to Jakarta EE developers to have a single api and therefore portability across the products – yes in this case.
Therefore in my mind the creation review should pass .
Passing creation review, in my view, is just the decision to collaborate on development work. To become a specification it has to pass the release review before which the technical details of the approach and api should have been be thrashed out and broad consensus achieved.
From: <> On Behalf Of Scott Stark
Sent: 23 November 2021 17:01
To: Jakarta specification discussions <>
Subject: Re: [] Jakarta RPC Creation Review Comments...

This is a more detailed reply. This has been posted to the creation review page, but I'm not seeing comments show up there, so repeating it here.

The Red Hat gRPC from Quarkus has come up with the following annotated pros/cons lists:


·        Marshaller; Clearly a great point and very interesting. The usage of JSON (as in their example) is somewhat weird (remember, gRPC is intended to be “fast”
·        REST Client-Like Clients; That’s a very neat idea. Allows reducing the service surface and implement ambassadors (integration with MP Fault Tolerance) It may not be practical in the sense that the method name must exactly match (which is not the case for the rest client as only the VERB + Path) must match.
·        Simplified Development model; It has always been a hurdle for gRPC (Java). It may require the user to write lots of message classes which could be automatically generated using protoc or similar tooling. Typically, the demo is using Lombok… That does not sound right (maybe records can help).


·        Blocking first; gRPC is non-blocking by default. Making the experience blocking first is wrong. Typically, bi-directional streaming is not possible. How is the gRPC back-pressure implemented with such an approach?
·        No tooling; We can see that it looks attractive, but the IDL and tooling around gRPC is also the reason it’s working: clear contract definition, handle schema evolution. Sending unstructured text messages feels wrong. Most of the time, it’s just because the tooling is not correctly integrated into the framework. In Quarkus, you drop the IDL, and you're done. No tooling.
·        Generic dispatching; The proposed approach will need dynamic dispatching at runtime. It will introduce a performance cost.
·        No implementation check; Nothing verifies that the implementation / client matches the IDL. It may introduce complex debugging, as name must exactly match (and proto method name <-> Java is NOT simple)
·        No gRPC metadata; The proposed development model does not allow custom gRPC fields or headers, which are often useful to pass metadata.

In summary, the approach is very interesting. It explores gRPC beyond the classical usage. At the moment, it feels that it still needs a lot of work to provide something relevant. In our opinion, this does not feel like gRPC, and not like JAX-RS, something in-between and it would benefit the project to have a multi-vendor implementation prototype(s) to validate the direction the specification should take.

On Nov 17, 2021 at 12:26:57 PM, Scott Stark <starksm64@xxxxxxxxx> wrote:
The concern Red Hat has is that the current proposal is exposing implementation choices that are not consistent with our implementation. Full support for protobuf for cross language support, streams/non-blocking and security are some issues that have come up in the review so far. On the review I have requested additional time to be able to provide a more complete response.
In the meantime, choice in our implementation can be found here:

On Nov 15, 2021 at 6:05:44 PM, Paul Nicolucci <pnicolucci@xxxxxxxxx> wrote:
I'm certainly willing to help! My Eclipse username is: pnicolucci
Paul Nicolucci
On Mon, Nov 15, 2021 at 10:57 AM William Lucy <wtlucy@xxxxxxxxxx> wrote:
Hi all,
I've just been able to review the spec proposal and the (great) presentation Aleksander gave - this is very promising. We implemented support for gRPC in Open Liberty last year, although our current implementation does not provide the same features as Helidon or the spec proposal. "Eliminating the need for IDL/proto files and build-time code generation" in particular will be great for users.
As far as naming goes, +1 for "Jakarta API for gRPC Services" - I agree it should be made clear that this spec is for gRPC.
Bill Lucy
IBM WebSphere Development
----- Original message -----
From: "Aleksandar Seovic" <aleks.seovic@xxxxxxxxx>
Sent by: "" <>
Subject: [EXTERNAL] [] Jakarta RPC Creation Review Comments...
Date: Fri, Nov 12, 2021 1:24 AM
Hi Kevin,
See my answers inline.
From: < Behalf Of Kevin Sutter
Sent: 11 November 2021 15:32
To: Jakarta specification discusions <>
Subject: [External] : [] Jakarta RPC Creation Review Comments...
I was just reviewing the material for this new Jakarta RPC spec project proposaland I see that the Creation Review processhas been initiated, with conclusion by Nov 24.  We have several comments that I would like to ensure that our wider Spec Committee can participate on.  (Providing comments on the proposal itself or the creation review record seem to get "lost" and most people do not see them.)

First off, the overall content and direction of the Jakarta RPC project proposal seems sound.  Creating a Specification based on the gRPC programming model is a good step forward.  But, ...
·        The name of the project is confusing.  I'm afraid it would be very easy to confuse Jakarta RPC with JAX RPC, and it's my understanding that this Spec is not a reincarnation of JAX RPC.  From the associated issue, it seems that Jakarta gRPC is also not acceptable since "gRPC" is already trademarked.  Since gRPC is based on "protocol buffers", maybe we should be more verbose and call it "Jakarta Protocol Buffering RPC" or "Jakarta pRPC", for short.  Just an  idea.  But, I think we need to do something other than "Jakarta RPC".
Mentioning Protocol Buffers explicitly is wrong, when one of the goals of the spec is to make it easier to use gRPC *without* ProtoBuf. gRPC itself is marshaller agnostic, and allows you to specify a different marshaller (if you really want to) for the request and response payloads for every single method. It is in no way tied to ProtoBuf at the architectural level.
What makes it tied to it at the moment is the tooling and the lack of documentation on how to support other formats. The spec we are proposing eliminates the need for tooling, for the most part, and makes it very easy to support any serialization format.
However, that does leave us in a bit of a limbo when it comes to the name… The two latest proposals were "Jakarta RPC" and "Jakarta for gRPC", and I guess Maria Teresa renamed the creation review issue to reflect the first option. I just posted a comment asking if a bit longer name of "Jakarta API for gRPC Services” would work, as I really see this spec as a gRPC equivalent of JAX-RS (Jakarta API for RESTful Web Services), and was at one point even proposing JAX-gRPC. Unfortunately, trademarks, both Oracle’s and CNCF’s do not make this easy… :-(
I do agree though that Jakarta RPC does not make it obvious enough that this spec focuses on gRPC, and implies other RPC frameworks may or should be supported, which is not where we want to go, imo. 
·        The initial set of committers is too single vendor heavy.  When we first created all of the Jakarta Specification Projects, we enlisted two reps from each strategic member plus other interested parties for the initial set of committers.  This helps diversify the community and provides some balance to the direction of the project.  I'd like to see us go back to those roots and encourage/enlist participation by other strategic members and limit the number of initial committers from any one organization.  To that end, IBM would like to put forth two names to participate on this spec project -- Bill Lucy and Paul Niccoluci.  (FYI, Bill would even be interested in co-leading the project, if Aleksander is looking for any assistance.)
This is just a consequence of the fact that we are proposing something we’ve built as part of Helidon for standardization, so I only added the people who have worked on the original design and implementation as committers.
I’m certainly happy (actually, hoping) to add contributors from other orgs, including Bill and Paul, and to have a chat with Bill to discuss whether it makes sense to add him as a lead. Personally, I’m happy to share the burden, especially with someone who is likely more familiar with the Jakarta processes than I am, but I want to make sure we are in agreement at least at the high level, as once again, what we are proposing is largely a derivative of something we’ve already built.
I would suggest that anyone interested watches the recording of the Jakarta Tech Talk I did on Tuesday, and then we can have a more informed conversation on contributors, leads, etc. In the meantime, I’ll add both Bill and Paul to the proposal, under the assumption that they will still want to help, even after watching me for 50 minutes or so ;-) I just need their emails.
·        Once a diverse set of initial committers is identified, then the selection of the patent license could be determined.  I know that Oracle took the initiative to create this project proposal (thank you!) and they would prefer the CPL license, but once we get more participation from the wider pool, would CPL still be the desired patent license?  With all of the initial participants coming from one organization, I think it sways the selection of the patent license.  As was done with the Config spec project, having an informal vote from the eventual diverse membership would produce a better view of the desired patent license.
I really have no comment on this one. I’ll leave it at that… ;-)


Kevin Sutter 
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)

_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit

_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit
_______________________________________________ mailing list
To unsubscribe from this list, visit

Back to the top