Incrementally moving towards Java EE 8 Support

[John D. Ament]

All

I wanted to open this up to a broader group, since we spoke of it briefly at this week's MP Hangout.  One of the questions that I put out there was if we could do Java EE 8 incrementally, rather than big bang.  From what I've heard, several vendors are already planning to move this way.  On the call, David noted that there may be some TCK issues with this approach.

The idea I had was an experiment about just adding JSON-B/JSON-P support.  From what I've gathered, JSON-B 1.0 requires JSON-P 1.1 so they need to be brought in together.  Does anyone see any issues if we expected, perhaps for MicroProfile 1.3, that implementations support JSON-P 1.1 and JSON-B 1.0 instead of the existing JSON-P 1.0 spec?

John

[Werner Keil]

John,

Incrementally, in what sense?

You mean, supporting JSON-P 1.1/JSON-B 1.0 but sticking to JAX-RS 2.0 and CDI 1.2 instead of their Java EE 8 counterparts?

As the other JSRs are mostly independent I guess it could work, bu having only few dependencies, I am not sure, if it's worth splitting the update across different versions.

Werner

[Ken Finnigan]

John,

I recall from the MP Hangout that we thought it best that any use of Java EE 8 specifications requires a 2.x release of either the individual spec or MicroProfile itself.

I think it's a good idea to have that major version separation between Java EE 7 and 8.

Ken

[Emily Jiang]

What is the use case to bring in JSON-P, JSON-B earlier? I would rather to bring the EE8 together in MP 2.0. In this way, it is much easier to explain and the dependencies are easier to manage.

Emily

[John D. Ament]

Ken,

I'll admit that I'm the big proponent of pushing this forward, so I won't immediately take no yet :-)  But if there's no interest I'm not going to push it forward.

I see there being benefit to adding partial support for Java EE 8.  For instance, JSON-P doesn't get you far.  It only adds support for JsonStructure and its derivatives.  Most Java developers want type safety, which is what you get with JSON-B.   So I actually see a large amount of benefit to including JSON-B as a component within MicroProfile 1.3

To be clear - this is only valid with JSON-B:

public class MyPojo {
  private UUID identifier;
  private String name;
// getters, setters
}

@Path("/api")
public class MyResource {
    @GET
    @Produces("application/json")
    public MyPojo get() { {
}

without providers having implementation specific annotations.

John

[Kevin Sutter]

John,
Thanks.  Although we don't have to wait for the "big bang" release of all of the Java EE 8 specs, I do agree that updating to JSON-B 1.0 and JSON-P 1.1 is more than a 1.x update.  This type of update would require the MicroProfile implementers to also provide implementations to JSON-B 1.0 and JSON-P 1.1, which might not mesh with their Java EE 7 implementations.  And, although these particular specs are pretty benign from a dependency viewpoint, mixing and matching of Java EE 7 and 8 technologies could prove difficult for some implementations. 

To that end, I think it's better to separate the Java EE 8 dependencies from our MP 1.x releases.  Maybe our first MP 2.0 release should only be JSON-B 1.0 and JSON-P 1.1?  And, then we could add the others CDI 2.0 and JAX-RS 2.1 in a later 2.1 release?

We have also stated in our MP spec that we are only specifying the minimum release of a given spec.  We have indicated that JSON-P 1.0 as a minimum.  If a vendor wants to utilize JSON-P 1.1, for example, then that should be acceptable.  But, we do not guarantee that this usage is compatible with other vendors supporting MP 1.2 (again as an example).

Several options exist for this gradual move to Java EE 8 technologies...

--  Kevin

[Ondro Mihályi]

I agree with John that adding JSON-B has a lot of added value and it misses a huge gap often filled by non-standard approaches (almost every Java EE 7 server provides mapping of objects to JSON in their own way).

It seems that there is a wide consensus about adopting JSON-B into MP 2.0. JSON-P 1.1 makes sense to me because it's just a minor improvement over the previous version.

Then there's JAX-RS. I believe that it adds a lot of value too, with SSE support to build asynchronous services and reactive API to help writing asynchronous response handlers. But SSE isn't very popular and desired these days and reactive API is just a syntactic sugar, and therefore upgrading JAX-RS isn't as important as including JSON-B and we can postpone it.

CDI 2.0 is mostly about enhancements here and there (asynch events count as an enhancement too for me). None of them is really necessary to move MicroProfile forward so upgrading CDI can be postponed easily.

In result, we have a few options for MP 2.x:

- upgrade all current EE specs to EE 8 (JAX-RS, CDI, JSON-P) and introduce JSON-B in MP 2.0 - this is what users would expect but it might delay implementations of MP 2.0 which aren't ready to integrate all these new APIs soon 

- introduce JSON-B, upgrade JSON-P and JAX-RS in MP 2.0 and then decide individually about each EE 8 API inclusion or upgrade, including CDI 2.0 (either when enough implementations exist or when it's useful for other MP APIs or usecases)

- introduce only JSON-B and upgrade JSON-P in MP 2.0, plan to upgrade JAX-RS in MP 2.1 and maybe CDI in MP 2.2 or later

While I prefer the first option to make impression that MicroProfile is agile and can absorb new standard APIs fast, any of the options makes sense if there are relevant reasons to support them.

--Ondro

[Ken Finnigan]

Ondro

I don’t disagree that MP 2.x should utilize Java EE 8 apis, and there are certainly various ways to bring it in as you outlined.

However, John is wanting to bring forward some of those specifications into a MP 1.3 release. That is where I disagree with Java EE upgrade path.

Ken

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a91c2894-bcff-4ae0-84e5-28c2ed617a0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Millidge]

OK so why don't we cut a Microprofile 2.x ASAP that uprevs to JavaEE8 for JavaEE derived apis and adds JSON-B while keeping the same point release versions of Microprofile apis?

We don't need to wait until everybody has a 2.x release ready to ship.

On Tuesday, 24 October 2017 23:07:58 UTC+1, Ken Finnigan wrote:

Ondro

I don’t disagree that MP 2.x should utilize Java EE 8 apis, and there are certainly various ways to bring it in as you outlined.

However, John is wanting to bring forward some of those specifications into a MP 1.3 release. That is where I disagree with Java EE upgrade path.

Ken

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Emily Jiang]

+1 on Ken! I prefer to bring all the relevant EE8 specs together in MP 2.0 1Q. I think this was the original suggestion anyway.

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a91c2894-bcff-4ae0-84e5-28c2ed617a0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/xmg3eZkdf0o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/47572688-C919-4C74-AC37-0333DB9247B9%40kenfinnigan.me.

For more options, visit https://groups.google.com/d/optout.

--

Thanks
Emily
=================
Emily Jiang
eji...@apache.org

[Ondro Mihályi]

OK then, it seems there's not much to disagree with MP 2.x

For MP 1.x, I agree with John A. that JSON-B would be really useful even in MP 1.x. Not having JSON-B in JavaEE/MicroProfile has been a pain and it's clearly a missing feature, often covered by the implementations in an incompatible way. Writing a lot of boilerplate code for mapping between objects and JSON using JSON-P is tedious. Nobody does it in practice and instead everybody relies on implementation details and the underlying library.

We've seen that in the conference demo where we discussed whether we can rely on JAX-B for automatic mapping. At least in the Schedule service it's still there. Using JAX-B for mapping to JSON is really non-standard, although it seems to work with various MP implementations.

So there's a real use case for including JSON-B in MP soon. If we want to be serious about maintaining the MP 1.x branch, I would at least consider including JSON-B. That would also require upgrading JSON-P to 1.1. However, I would do it as a separate proposal to MP 1.x, which can be discussed on its own and possibly rejected.

Ondro

[Ondro Mihályi]

I mean, the key point from my previous message is:

While MP 2.0 should be based on Java EE 8, there's no reason to pull parts of Java EE 8 into MP 1.x it there's a value in it. And I believe that there's an overwhelming value in JSON-B.

--Ondro

[Kevin Sutter]

Ondro,
I disagree with your statement that it's okay to pull parts of Java EE 8 into MP 1.x.  We've discussed this many times on the hangouts and in various threads (including this one).  MP 1.x is associated with Java EE 7 technologies.  If and when we decide to pull in some Java EE 8 technologies, we need to change our major version.  Customers that are currently happy with the MP 1.x releases on their Java EE 7 app servers would be very surprised (upset) if an MP 1.3 release (for example) would require an update to Java EE 8 technologies.  No matter how minor of an update this entails.

If a vendor wants to provide json-b support with their MP 1.x offering, that is up to them.  But, going beyond the spec of MP 1.x is a vendor offering and the resulting application may not be portable to other solutions.

If json-b is important, then someone could start an MP 2.x release train and only include json-b and the json-p update.  But, at a recent hangout, it was decided that this could wait until the 1Q 2018 train since we already have our hands full with the MP 1.3 release in 4Q 2017.

--  Kevin

[John D. Ament]

Kevin,

I'm reading through the notes from the last hangout, that's not what was decided.

I have two goals within this thread:

- Understand what the TCK issues are with upgrading to newer versions of Java EE specs.  This was a statement made by David Blevins, I'm not sure if he clarified what the actual issues were on the call.

- Propose some number (more than likely just the previously mentioned ones) of EE8 APIs for inclusion in a MP release < 2.0

I can understand some of the potential issues with upgrading to EE8 APIs for certain components.  For instance, there are some behavioral differences in the spec around CDI 2.0, applications likely wouldn't notice the one in particular I'm thinking of (Usage of @Destroyed qualifier for events) since we found both impls did it the same way.

John

[Mark Struberg]

Hi John! 

The EE spec explicitly disallows it to add newer versions of a spec to any certified container. Except maybe Maintenance Releases of a spec - and only if the MR did not change the API.

The some TCK e.g. explicitely check the number of methods and their parameters for any given spec interface.

 

LieGrue,

strub

[Kevin Sutter]

Another issue with the TCK and CTS testing and certification is the mix-and-match of Java EE technologies, or the difficultly in doing so.  The Java EE compatibility page shows the vendors at specific Java EE versions:
http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html

It can be very difficult, sometimes impossible to pass a given Java EE 8 technology TCK and still have it interoperate with a Java EE 7 application server.  Especially those technologies which are tightly coupled with other technologies.

For example, suppose we decided to upgrade MP 1.3 to use CDI 2.0 from Java EE 8.  I would venture to say that none of our (collective our, not just speaking from an IBM perspective) Java EE 7 compliant application servers would be able to support that configuration.  We would have to step up to supporting all of Java EE 8 before we could support MP 1.3.

I see that John has this topic on our agenda for tomorrow.  Maybe we can flesh out the discussion at that time.

Thanks, Kevin

[John D. Ament]

Kevin,

I just re-read tomorrow's agenda.  I don't have this topic on the agenda.  Please let me know which item you think is pointing to this subject.

Based on today's Rest Client call, I'm dropping my push for this.  We came up with an agreeable alternative to solve rest client's problems.

- MP Rest Client 1.0 will require automatic registration, in some form, of a JSON-P 1.0 provider.

- MP Rest Client that ships with a MP release that supports Java EE 8 technologies will require automatic registration of both JSON-P 1.1 and JSON-B 1.0 providers.

- Implementations may support automatic registration of additional providers as they see fit through non-portable means.  Likewise, applications may deliver their own providers.

John