Skip to main content

[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

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@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 (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 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


Back to the top