Re: [ee4j-community] Some guidelines for Maintenance Releases (MRs) of J

[reza_rahman <reza_rahman@xxxxxxxxx>]

Although this is far too premature, if we must live with a new package and brand name that does not really prominently feature Java, the best bet would be something that can be clearly positioned as an "improvement".

The key could be standardization through an existing body with some standardization credibility such as ISO, ECMA or OASIS. In particular I would imagine the OASIS folks would be pretty receptive. I fear a net new standards body or consortium will have the least to offer in terms of business or technical credibility. In fact even the JCP is weak in this regard even after years of effort to change industry perceptions.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: will.lyons@xxxxxxxxxx

Date: 1/8/18 6:24 PM (GMT-05:00)

To: ee4j-community@xxxxxxxxxxx

Subject: Re: [ee4j-community] Some guidelines for Maintenance Releases (MRs) of Java EE 8 Specifications

I agree with Bill's replies.

Here is what the EE4J FAQ says about the javax.* namespace:

Will EE4J use javax package names?
We recognize this is important to compatibility. We have not yet formalized the plan, but we intend to enable use of existing javax package names to provide compatibility. We also intend to enable extension of existing javax namespaces (e.g. javax.servlet.*) to provide continuity and enable evolution of existing APIs. Our current expectation is that net new packages will use a different namespace naming convention.

    Will

On 1/8/18 4:56 PM, Bill Shannon wrote:

Werner Keil wrote on 01/ 8/18 01:40 PM:

Will,

Thanks for the update.

Can you tell us what this means for backward-compatibility and ease of adoption?

>   Oracle does not recommend or support use the JCP process for any future Java EE 8 functional enhancements.

effectively means it does not support the use of the javax.* namespace either.

No, that's not what it means.  Please see the EE4J FAQ.

What does that mean for JSON-B (Yasson 1.1 still claims to implement JSR 367 without change) or more drastically EclipseLink 3.x? https://projects.eclipse.org/projects/rt.eclipselink/releases/3.0.0

There are 3 quarterly releases planned for EclipseLink 3. At least 3.0.0 as  Major release (API breakage) 

What does that mean for JPA? The relatively small MR of JPA 2.2 would not offer  Full Java SE 9 compatibility for EclipseLink 3 without an API upgrade likely also something like JPA 3 or at least something that declares full Java SE 9 modules. 

Where is this supposed to happen and under what package name, javax.persistence or something else?

Functional enhancements of these APIs should occur as part of the EE4J project, using whatever process is defined there.  Again, see the EE4J FAQ.

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community