[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Feedback to Joint Community Open Letter on Java EE Naming and Packaging

Heiko,

Thanks for coming back to that.Â
Glad to discuss a concrete example like javax.servlet.http4 orÂ
javax.security.enterprise.authentication.mechanism.openid for a future update to Java Enterprise Security or whatever the name shall be (as Java EE Security seems off the table ;-)

This is a bit clearer than talking about "net new packages".

WernerÂ



On Tue, Jan 16, 2018 at 5:33 PM, <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: Feedback to Joint Community Open Letter on Java EE Naming
   and Packaging (Heiko Rupp)
 Â2. Re: Feedback to Joint Community Open Letter on Java EE Naming
   and Packaging (Ryan Cuprak)


----------------------------------------------------------------------

Message: 1
Date: Tue, 16 Jan 2018 17:20:17 +0100
From: "Heiko Rupp" <hrupp@xxxxxxxxxx>
To: "EE4J community discussions" <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Feedback to Joint Community Open Letter
    on Java EE Naming and Packaging
Message-ID: <6EBAC0B6-F0C4-49DB-9BDB-B4C3FC769040@xxxxxxxxxx>
Content-Type: text/plain; charset=utf-8; format=flowed

Will,

thank you for your comprehensive write-up.

On 16 Jan 2018, at 16:04, will.lyons@xxxxxxxxxx wrote:

> ?  We are intending to allow certain uses of existing javax
> packages as those packages evolve for compatibility.

I understand that Oracle wants to preserve the Java brand.
As the package javax.enterprise already exists, couldn't
this be treated as a case of #2 like javax.servlet, where
I understand that Servlet 2018 spec could introduce a
javax.servlet.http4.* sub-package?

On the other hand, I personally would not mind using
ee4j as new top-level package and not stuff it into
javax.enterprise.*, as those would be new imports into
code anyway.

 ÂHeiko


--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht M?nchen HRB 153243
Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Michael O'Neill,
Eric Shander


------------------------------

Message: 2
Date: Tue, 16 Jan 2018 11:33:04 -0500
From: Ryan Cuprak <rcuprak@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Feedback to Joint Community Open Letter
    on Java EE Naming and Packaging
Message-ID: <C34ED8C2-B51B-4030-BF25-FF2C318269DA@xxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Hello,
ÂI just wanted to express my disappointment specifically with the Java EE branding. While I applaud the efforts Oracle has been making in donating Java EE to the Eclipse Foundation, the lack of brand continuity going forward I believe is going to hurt the platform. I disagree that Java EE is perceived as being an Oracle technology. From my experience, it perceived as a standard with implementations from Oracle, IBM, Apache, etc. Ultimately, the confusion over Java EE branding I think will hurt the commercial containers (like WebLogic) as Java EE may no longer be viewed as a long-term stable platform with a future.
ÂTransitioning Java EE to new stewards and establishing new processes for the platform is a major undertaking. Rebranding is very risky under the best of circumstances. I hope that this position will be rethought or modified. Maintaining name continuity for at least a couple of years until the new process is up and running would go a long way to ensuring the success of this platform.

-Ryan
Connecticut Java Users Group

> On Jan 16, 2018, at 10:04 AM, will.lyons@xxxxxxxxxx wrote:
>
> Hello -
>
> Reza Rahman has recently posted a Joint Community Open Letter on Java EE Naming and Packaging <https://javaee-guardians.io/2018/01/02/joint-community-open-letter-on-java-ee-naming-and-packaging/>. ÂOur feedback is given below - most of it is context explaining our direction. ÂWe hope it is helpful.
>
> Oracle has previously communicated that it intends to work with the EE4J community to:
> 1) Define a branding strategy for the platform, including a new name for Java EE to be determined.
> 2) Enable use of existing javax package names, and enable extension of existing javax namespaces (e.g. javax.servlet.*) to enable compatibility and evolution of existing APIs.
> 3) Use a different namespace naming convention, i.e. different from ?javax.*?, for net new APIs/technologies.
>
> Note that doing the above remains work in process, but it remains our intent.
>
> The open letter requests that Oracle and other EE4J stakeholders work together:
> 1) To allow the new platform to retain the Java EE name
> 2) To allow use of existing ?javax? packages for existing technologies
> 3) To allow use of the ?javax.enterprise? package for new technologies
>
> Oracle has already expressed its intent to do what is requested in point #2 above. ÂThis would allow for compatibility between EE4J releases and existing Java EE releases at the package level. ÂWe will focus on points #1 and #3 below. ÂWhy not allow use of the Java EE name, and why not allow use of the javax.enterprise namespace for all new EE4J technologies?
>
> The industry has changed since the Java EE development process was originally created. The process was not seen as being nimble, flexible or open enough. Our shared goal is to create a more nimble process, with more flexible licensing, and more open governance that is not dependent on a single vendor. We believe this will encourage more participation and innovation. We see general support for this new direction from across the community.
>
> This new direction implies many changes, starting with a change in the technology development process. ÂThe Java EE process, or to be more specific, the JCP process that was used for Java EE development, is a highly structured process that grants specification leads significant influence over how technologies are specified and implemented. The EE4J process will be different. It will be more open. Single vendors including Oracle will continue to contribute, but will no longer have the same level of influence over how new EE4J technologies evolve. We believe there is consensus that this is a positive step for the community.
>
> This new development process drives choices around use of the Java EE name, and use of the javax.* package names for new technologies. The Java EE and javax.* names leverage the Java trademark, and indicate that the source of these technologies is Oracle and community processes managed by Oracle. As a critical identifier of the source of products to our users, we must continue to reserve use of such names using the Java trademark to serving that fundamental source identifying function. This will help us to maintain the Java trademark, which is in Oracle?s interest and in the community?s interest. We recognize there are likely to be requirements to create new versions of existing Java EE specifications that were already created using the existing JCP process. We believe we can work out an approach to allow use of javax.* names for extensions to these existing specifications in order to accommodate these requirements. ÂHowever, if we adopt a new process for new EE4J technologies
Â, as is desired by the community, we believe we must require that a new namespace be used for the new EE4J technologies that are developed using that process, and a new brand (other than Java EE) that includes these new technologies. There is a tradeoff here, and we believe that the net benefit of the new process warrants the adoption of a new namespace for new EE4J technologies, and a new brand.
>
> We will work with the EE4J community to mitigate continuity concerns that accompany this change. ÂWe are making it very clear that EE4J will be an evolution of existing Java EE 8 technologies:
> ?  We are contributing our existing GlassFish Java EE 8 Reference Implementation sources to EE4J.
> ?  We will contribute our existing TCKs.
> ?  We are intending to allow certain uses of existing javax packages as those packages evolve for compatibility.
> ?  We are intending to allow use of existing specification names for component specifications.
> ?  We are building an initial EE4J implementation that is intended to be both Java EE 8 and ?EE4J? compatible.
> ?  We will work with the EE4J community to promote the new brand.
>
> These are positive steps we can take.
>
> We support the efforts of the EE4J Project Management Committee to make branding recommendations to the Eclipse Foundation. We encourage the community to support the effort as well, and extend thanks to all for the continued interest in Java EE and EE4J technologies. ÂAnd we hope to deliver soon more new projects with GlassFish sources contributed to EE4J!
>
> Thanks
>
> Will
>
> _______________________________________________
> 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/20180116/7de85d9a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180116/7de85d9a/attachment.sig>

------------------------------

_______________________________________________
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 42
*********************************************