[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-community] Some guidelines for Maintenance Releases (MRs) of Java EE 8 Specifications
|
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.
No, that's not what it means. Please see the EE4J FAQ.
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