[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

Emily,

Thanks for the confirmation. That also confirms what e.g. Bill Shannon said in an earlier thread.
The statements about "Oracle does not support or recommend using the JCP for updates of Java EE 8 specs" sounded quite irritating, but if either these existing Specs (like Servlet, JPA,...) can still use their javax namespace even without a new JSR or Eclipse (like JSR 382) may file one or more JSRs for EE4J where appropriate, that sounds much better.

JSR 381 initially proposed "visrec" only, it seems they were not so familiar with the JCP, it would have been a legal Java package name (take "jdk" or what the CDI implementation Dagger does) but I suggested whether they may not consider "javax.visrec" to be more consistent with the other package namespace.

WernerÂ



On Wed, Jan 10, 2018 at 11:02 AM, <ee4j-community-request@xxxxxxxxxxx> 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 (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
*********************************************