| Re: [ee4j-community] Some guidelines for Maintenance Releases (MRs) of Java EE 8 Specifications |
Werner
Send ee4j-community mailing list submissions to
ee4j-community@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
or, via email, send a message with subject or body 'help' to
ee4j-community-request@eclipse.org
You can reach the person managing the list at
ee4j-community-owner@eclipse.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."
Today's Topics:
1. Re: Some guidelines for Maintenance Releases (MRs) of Java EE
8 Specifications (Emily Jiang)
------------------------------------------------------------ ----------
Message: 1
Date: Wed, 10 Jan 2018 10:02:40 +0000
From: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Some guidelines for Maintenance Releases
(MRs) of Java EE 8 Specifications
Message-ID:
<CAECq3A9uRptjVtyTK=HP28e0ZxHvydQK6munvxXtfGEd5Y_rjw@mail. >gmail.com
Content-Type: text/plain; charset="utf-8"
For JSR382, when the proposal was submitted, we listed the package
javax.config.* usage and it was approved. I checked with Heath during
JavaOne last year and she confirmed that this spec can still use
javax.config.*.
Emily
On Tue, Jan 9, 2018 at 3:03 PM, <will.lyons@xxxxxxxxxx> wrote:
> Werner -
>
> This needs to be formalized, but as an example of an extension of the
> existing javax namespace, there is an existing javax.servlet.http package.
> Let's say an http3 standard came out, and EE4J wanted a new version of
> the Servlet spec to support it, then that's something that might be
> considered an extension for which a new javax.servlet.http3 package might
> be created for.
>
> However if someone wanted to create a net new specification in a new
> functional area for which there is currently no specification or JSR we
> would expect that a net new package using a new namespace (other than
> javax.*) to be used.
>
> The examples above are intended for when EE4J is in steady state
> operation. JSR 382 was introduced during the transition period. I assume
> we will work something out for it which makes sense for the EE4J community.
>
> Will
>
> On 1/8/18 7:10 PM, Werner Keil wrote:
>
> Will,
>
> Thanks for the clarification.
>
> >current expectation is that net new packages will use a different namespace
> naming convention.
>
>
> Many details will have to be fleshed out, e.g. if an actual base element
> like javax.servlet.Servlet or ServletConfig should get a new method (e.g.
> just hypothetically to support JSR 382 ;-) it would be fine to stay where
> it is.
>
> If however, EE4J was to introduce some totally new element, I assume along
> the lines of what we saw in Java SE (the "jdk" package) it could work to
> add this to a new package, if that's what "new net packages" means?
>
> Werner
>
>
> On Tue, Jan 9, 2018 at 12:55 AM, <ee4j-community-request@eclipse.org >
> wrote:
>
>> Send ee4j-community mailing list submissions to
>> ee4j-community@xxxxxxxxxxx
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>> or, via email, send a message with subject or body 'help' to
>> ee4j-community-request@eclipse.org
>>
>> You can reach the person managing the list at
>> ee4j-community-owner@eclipse.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of ee4j-community digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Some guidelines for Maintenance Releases (MRs) of Java EE
>> 8 Specifications (will.lyons@xxxxxxxxxx)
>> 2. Re: Some guidelines for Maintenance Releases (MRs) of Java EE
>> 8 Specifications (reza_rahman)
>>
>>
>> ------------------------------------------------------------ ----------
>>
>> Message: 1
>> Date: Mon, 8 Jan 2018 18:24:51 -0500
>> From: will.lyons@xxxxxxxxxx
>> To: ee4j-community@xxxxxxxxxxx
>> Subject: Re: [ee4j-community] Some guidelines for Maintenance Releases
>> (MRs) of Java EE 8 Specifications
>> Message-ID: <501dc03d-e730-b0c8-4b2c-eb4663349f45@xxxxxxxxxx >
>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>>
>> 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
>> > <https://www.eclipse.org/ee4j/faq.php#packages >.
>> >
>> >> 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 <https://www.eclipse.org/ee4j/faq.php#jcp >.
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://dev.eclipse.org/mailman/private/ee4j- community/
>> attachments/20180108/946572bd/attachment.html>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 08 Jan 2018 18:55:45 -0500
>> From: reza_rahman <reza_rahman@xxxxxxxxx>
>> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>> Subject: Re: [ee4j-community] Some guidelines for Maintenance Releases
>> (MRs) of Java EE 8 Specifications
>> Message-ID: <mailman.427.1515455748.19330.ee4j-community@xxxxxxxxxxx >
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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
>>
>>
>>
>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://dev.eclipse.org/mailman/private/ee4j- community/
>> attachments/20180108/b5d7c13f/attachment.html>
>>
>> ------------------------------
>>
>> _______________________________________________
>> 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
>>
>>
>> End of ee4j-community Digest, Vol 5, Issue 10
>> *********************************************
>>
>
>
>
> _______________________________________________
> ee4j-community mailing listee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/ee4j- community
>
>
>
> _______________________________________________
> 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
>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang@xxxxxxxxxx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180110/7b7a019a/attachment. html
------------------------------
_______________________________________________
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
End of ee4j-community Digest, Vol 5, Issue 13
*********************************************