[
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
|
Hi,
On 1/8/18 10:40 PM, Werner Keil wrote:
Will,
Thanks for the update.
Can you tell us what this means for backward-compatibility and ease of
adoption?
[..]
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?
Speaking just about JPA/EclipseLink itself here:
While EclipseLink is JPA RI, its APIs are not just JPA related
(javax.persistence.*) - and at this point we do not plan any breaking
changes within this area. There's also a lot of other APIs in
'org.eclipse.persistence.*' packages coming not only from pre-JPA times
(aka Native EclipseLink APIs) which we would like to change/update (ie
possibly remove stuff which is deprecated for a long time already) and
this is where we are planning to do changes and from where possible API
breakage may be coming from.
thanks,
--lukas
This is just one example, but also a JSR (338) I served in its EG and
customers use quite a bit, so they are equally concerned about its future.
Thanks,
Werner
On Mon, Jan 8, 2018 at 6:00 PM, <ee4j-community-request@xxxxxxxxxxx
<mailto:ee4j-community-request@xxxxxxxxxxx>> wrote:
Send ee4j-community mailing list submissions to
ee4j-community@xxxxxxxxxxx <mailto:ee4j-community@xxxxxxxxxxx>
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
<https://dev.eclipse.org/mailman/listinfo/ee4j-community>
or, via email, send a message with subject or body 'help' to
ee4j-community-request@xxxxxxxxxxx
<mailto:ee4j-community-request@xxxxxxxxxxx>
You can reach the person managing the list at
ee4j-community-owner@xxxxxxxxxxx
<mailto:ee4j-community-owner@xxxxxxxxxxx>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."
Today's Topics:
1. Some guidelines for Maintenance Releases (MRs) of Java EE 8
Specifications (will.lyons@xxxxxxxxxx
<mailto:will.lyons@xxxxxxxxxx>)
2. Re: Devoxx EE4J BoF (Heiko Rupp)
----------------------------------------------------------------------
Message: 1
Date: Sun, 7 Jan 2018 17:25:13 -0500
From: will.lyons@xxxxxxxxxx <mailto:will.lyons@xxxxxxxxxx>
To: ee4j-community@xxxxxxxxxxx <mailto:ee4j-community@xxxxxxxxxxx>
Subject: [ee4j-community] Some guidelines for Maintenance Releases
(MRs) of Java EE 8 Specifications
Message-ID: <53cd3fe2-021d-981b-55f2-a23336884007@xxxxxxxxxx
<mailto:53cd3fe2-021d-981b-55f2-a23336884007@xxxxxxxxxx>>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello -
Oracle continues to work with members of the Java EE community to
contribute GlassFish and Java EE 8 technologies to the Eclipse
Enterprise for Java (EE4J) project at the Eclipse Foundation. We
expect these technologies to evolve within EE4J, and we do not expect
there will be a ?Java EE 9? or a GlassFish Reference Implementation for
it. However, as stated previously in the EE4J FAQ
<https://www.eclipse.org/ee4j/faq.php
<https://www.eclipse.org/ee4j/faq.php>>, Oracle may deliver maintenance
releases of GlassFish 5.0 and related Java EE 8 JSRs.
The first example of a Java EE 8 JSR Maintenance Release (MR) has
surfaced. Future releases of Java SE will require clearer demarcation
of those aspects of the Java Transaction API specification (JSR 907)
that are a) implemented in Java SE and b) implemented in Java EE
implementations. An MR of JSR 907 has been opened to provide this
clarification and demarcation, and is available at:
https://jcp.org/en/jsr/detail?id=907
<https://jcp.org/en/jsr/detail?id=907>
No functional changes to the JTA specification are planned as part of
this MR. Oracle has proposed to use the JCP process to review this MR,
while the Eclipse Enterprise for Java (EE4J) specification process is
being defined. The use of the JCP process for this Java EE
specification is only intended for this maintenance purpose during this
interim period when the EE4J process is being defined. The Eclipse
Foundation will act as co-lead of the JTA specification with Oracle, and
Mark Little of Red Hat will serve in the role of co-spec lead, and
Oracle, Eclipse, and Red Hat have jointly agreed to represent the
interests of EE4J in leading this specification.
This MR raises a general question of when MRs for current Java EE 8
specifications is appropriate. We thought it would be useful to
establish and communicate guidelines for using the MR process for Java
EE 8 specifications.
Oracle recommends and supports the use of EE4J-driven processes for
functional enhancements to Java EE 8 specifications, and does not
recommend or support use the JCP process for any future Java EE 8
functional enhancements. However, from time to time there may be valid
reasons for providing MRs of Java EE 8 specifications.
Appropriate reasons for introducing MRs to current Java EE 8
Specifications are the following:
i) Fixing potential errata in specifications, in order to clarify or
correct the specifications to align with the original intent of the
specification.
ii) Addressing potential security vulnerabilities that may be
associated with current specifications.
iii) Enabling clearer demarcation of those aspects of Java EE
specifications that are implemented in Java SE and those that are
implemented in Java EE, as required to enable evolution of the Java SE
platform in a timely manner. The technologies currently shared by EE
and SE, and the plan to achieve clear demarcation, are publicly covered
in http://openjdk.java.net/jeps/320
<http://openjdk.java.net/jeps/320>. Any material changes to this JEP
will be shared directly with the EE4J PMC.
As Java EE Spec lead, Oracle will discourage the use of the JCP process
for MRs to Java EE 8 Specifications for any other reason than those
given above. The EE4J process should be used. If some additional
reason for a Java EE 8 MR is identified, Oracle will encourage that the
spec lead or expert group proposing the MR review the reason for the MR
with the EE4J Project Management Committee (PMC). The EE4J PMC will
determine if there is a valid reason for the MR and will update the list
above as appropriate.
We hope this note provides context for the JTA MR above and review of
other potential MRs going forward. Thanks very much.
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180107/eeef87c7/attachment.html
<https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180107/eeef87c7/attachment.html>>
------------------------------
Message: 2
Date: Mon, 08 Jan 2018 08:52:45 +0100
From: "Heiko Rupp" <hrupp@xxxxxxxxxx <mailto:hrupp@xxxxxxxxxx>>
To: spousty@xxxxxxxxxx <mailto:spousty@xxxxxxxxxx>, "EE4J community
discussions"
<ee4j-community@xxxxxxxxxxx
<mailto:ee4j-community@xxxxxxxxxxx>>
Subject: Re: [ee4j-community] Devoxx EE4J BoF
Message-ID: <84E848A4-E597-4CF2-A8BB-A41FF3A5A1C7@xxxxxxxxxx
<mailto:84E848A4-E597-4CF2-A8BB-A41FF3A5A1C7@xxxxxxxxxx>>
On 5 Jan 2018, at 19:20, Steven Pousty wrote:
> I put in for Devoxx FR - if I get my talk I can certainly help in
the BOF.
> I can probably also get some other Red Hatters as well
I have submitted a talk to DevoxxFR and if that is accepted,
I may be able to chime in as well. My French is rusty, but
I would certainly be there.
------------------------------
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx <mailto: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
<https://dev.eclipse.org/mailman/listinfo/ee4j-community>
End of ee4j-community Digest, Vol 5, Issue 5
********************************************
_______________________________________________
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
