Re: [ee4j-community] Use of javax.* in new EE4J projects

[Werner Keil <werner.keil@xxxxxxxxx>]

Again, in case it may have been unclear or not so precisely formulated, for all JSRs that have so far been filed and accepted under jcp.org it IS allowed.

JCache which has a pending MR1 won't even be allowed to suddenly change its package from javax.cache to (hypothetically) "ee4j.cache" or whatever. 

There are fundamental compatibility requirements, so unless a completely new JSR was filed under the number XYZ (384 or above) saying "This is version Y of a JSR previously X" and that new JSR gets approved by the EC to use another package, the existing ones will be used.

Speaking of JCache, its detail page is hopelessly outdated, still saying

"javax.util.jcache in j2ee (although it could be useful in j2se)"

but again, the code and API is what counts here.

For any future standard or "pseudostandard" nobody knows. 

If the JCache API or any other former JSR went to another namespace then it would effectively become a fork of the current Java standard living in its own module and package space. So far this is pure speculation unless the EE4J PMC was to declare what it intends to do.

Oracle is just one member of that PMC, so it likely won't have the last or only word ;-)

HTH,

Werner

On Mon, Nov 13, 2017 at 7:01 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: Use of javax.* in new EE4J projects (Werner Keil)
   2. Re: Use of javax.* in new EE4J projects (Markus KARG)


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

Message: 1
Date: Mon, 13 Nov 2017 18:17:47 +0100
From: Werner Keil <werner.keil@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Use of javax.* in new EE4J projects
Message-ID:
        <CAAGawe0M1K_YyVvQ4RFoRoBnGW8uSv-iUAsK8h3LdROjp7aT0Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Kevin,

Thanks for the concrete example. As for JNoSQL, while details on how
exactly it might be incorporated into another "standard" or umbrella are as
vague and to be paved as in other cases, the (Eclipse) project already
exists under http://jnosql.org/

Therefore close to what you hinted, the public API uses "org.jnosql.*"
which is also registered (whether or not it's been delegated to Eclipse
Foundation not sure, but it that'll be its package for some time I trust it
will be handled like e.g. microprofile.io) and until the question of a RI
or default implementation is further laid out, other parts like Artemis
also share this package. It is possible some implementation modules could
use "org.eclipse.jnosql" instead.

Werner Keil | JCP Executive Committee Member, JSR 363 Maintenance Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer

Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @TamayaConf |
@OpenDDR | #EclipseUOMo
Skype werner.keil


On Mon, Nov 13, 2017 at 6:00 PM, <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: Use of javax.* in new EE4J projects (Kevin Sutter)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 13 Nov 2017 08:05:47 -0600
> From: "Kevin Sutter" <sutter@xxxxxxxxxx>
> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Subject: Re: [ee4j-community] Use of javax.* in new EE4J projects
> Message-ID:
>         <OFC11BBDB4.54B010C4-ON862581D7.004D179D-862581D7.
> 004D6EC6@xxxxxxxx.collabserv.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Getting back to Greg's original post...  Since JCache has already been
> approved by the JCP, then the continued use of javax.cache.* should be
> allowed within EE4J.  It's the "net new" technologies that would be
> incorporated into EE4J that would require an alternate package name.  For
> example, if a new spec is developed at EE4J -- let's say for NoSQL.  Then,
> that project would not be allowed to use javax.nosql.*.  This new project
> would have to use something like org.ee4j.nosql (or whatever is decided).
>
> ---------------------------------------------------
> Kevin Sutter
> STSM, MicroProfile and Java EE architect
> e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
> phone: tl-553-3620 (office), 507-253-3620 (office)
> LinkedIn: https://www.linkedin.com/in/kevinwsutter
>
>
>
> From:   Guillermo Gonz?lez de Ag?ero <z06.guillermo@xxxxxxxxx>
> To:     EE4J community discussions <ee4j-community@xxxxxxxxxxx>
> Date:   11/13/2017 01:02 AM
> Subject:        Re: [ee4j-community] Use of javax.* in new EE4J projects
> Sent by:        ee4j-community-bounces@eclipse.org
>
>
>
> Exactly.
>
> It's fine to abandon the Java EE brand and have a fresh start, but Java EE
> is not only about EJBs and other "heavyweight" technologies. JSON-B is an
> EE spec that's clearly useful outside Java EE and I hope Jackson and Gson
> will implement the spec at some point. I doubt that would happen if the
> package name would be e.g. "org.ee4j.json.bind". I don't think we would
> have had such a list of Servlet containers if Servlets had been created
> from an external entity.
>
> JSON-B, JSON-P, JCache, JAXB (not available in Java 9 by default, needs
> the "java.se.ee" module) are good examples of specs I think are totally
> useful outside Java EE environments. Sure we can expect these existing
> specs to retain the javax packages, but what will happen with new specs?
> Will we still need to use the JCP if we want to promote some spec to still
> be part of the Java library?
>
> We already know Oracle's opinion on this, but now that we already have the
> PMC set up, I'd like to hear other vendors thoughts and how you think this
> can be tackled.
>
> Regards,
>
>
> Guillermo Gonz?lez de Ag?ero
>
> El dom., 12 nov. 2017 a las 22:38, Reza Rahman (<reza_rahman@xxxxxxxxx>)
> escribi?:
> To be clear, the Java EE Guardians community also believes a clean break
> from the Java EE brand is potentially a good thing. The issue is a largely
> forced distance from the Java brand as well, not just the Java EE brand. I
> think it's hard to argue the Java brand is not a good thing to retain.
>
> I think the linked JotForm default text makes the distinction quite clear.
> The text actually largely describes our community's joint position
> already. Perhaps it is worth a brief read. There is no need to ultimately
> submit the form if one is not compelled.
>
> Sent from my iPhone
>
> On Nov 12, 2017, at 4:16 PM, Martijn Verburg <martijnverburg@xxxxxxxxx>
> wrote:
>
> I'm going to play Devil's Advocate here and say that sadly the Java EE
> brand is seen as a negative thing.  Unfortunately we were never able to
> shake off the dire reputation of J2EE, despite the vast improvements to
> the platform.
>
> I think a clean break is actually a *good* thing.
>
> Cheers,
> Martijn
>
> On 12 November 2017 at 18:05, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
> I am very glad someone like yourself from the vendor/EC side see this as
> an issue and is willing to publicly identify this as an issue.
>
> This is by far one of the biggest issues we have identified so far in the
> Java EE Guardians community. As an initial step, we have asked the
> community to send Oracle and other key EE4J stakeholders direct and
> personal feedback on this: https://form.jotform.com/72648425384161. I
> suspect it is the sole matter with regards to EE4J that these folks have
> been reached out to about the most.
>
> Unfortunately clearly the community has still not really been heard on
> this matter. While I am sure the root cause of this issue is Oracle's
> legal and branding departments being overly rigid, this is something that
> Oracle executives can intervene on if they deemed it worthy of solving.
>
> From the Java EE Guardians community, our likely next steps are to arrive
> at a joint open letter asking EE4J stakeholders to address this issue -
> Oracle being the main party of our request. Any support you can lend us in
> this regard, even if only moral, would be helpful and highly appreciated.
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: Greg Luck <gluck@xxxxxxxxxxxx>
> Date: 11/3/17 2:07 PM (GMT-05:00)
> To: ee4j-community@xxxxxxxxxxx
> Subject: [ee4j-community] Use of javax.* in new EE4J projects
>
> Hi
>
> Had a call with Mike today about moving JCache across to EE4J.
>
> We have JCache 1.1 in the JCP review process now and it should be out in a
> few weeks? time. So we could consider moving after that point.
>
> The biggest issue to me is that, at least currently, any new APIs will not
> be allowed to use javax. Today we use javax.cache. This would mean that
> JCache 2 would need to change its package name. We have 13 implementations
> out there and a huge amount of user code that uses javax.cache. This would
> be an extremely disruptive change.
>
> In our case Oracle is a copyright owner along with myself for the spec. As
> an owner, Oracle if they wished, should be able to allow JCache 2 to
> continue to use the javax.cache package even though the process has
> changed from JCP to the yet unnamed and to be formed Eclipse Community
> Process.
>
> Interested in anyone?s thoughts on this.
>
> Regards
>
> Greg Luck
>
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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
> _______________________________________________
> 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
> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.
> eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=
> jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=
> b_vTeQOmwB1585BadfMll-Cc5aCWacnokkUnueEf-qM&s=1aURO5_
> qrTH4KUGplh6f883VN8ViLWd64OZ9v3qZ5-A&e=
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/
> 20171113/3aea927b/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 3, Issue 25
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171113/38958696/attachment.html>

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

Message: 2
Date: Mon, 13 Nov 2017 19:01:21 +0100
From: "Markus KARG" <markus@xxxxxxxxxxxxxxx>
To: "'EE4J community discussions'" <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Use of javax.* in new EE4J projects
Message-ID: <003401d35ca9$6cd2f770$4678e650$@eu>
Content-Type: text/plain; charset="utf-8"

I assume what people like to hear is not "SHOULD BE allowed" but a clear statement of Oracle that reads "it IS allowed".

-Markus





From: ee4j-community-bounces@eclipse.org [mailto:ee4j-community-bounces@xxxxxxxxxxx] On Behalf Of Kevin Sutter
Sent: Montag, 13. November 2017 15:06
To: EE4J community discussions
Subject: Re: [ee4j-community] Use of javax.* in new EE4J projects



Getting back to Greg's original post...  Since JCache has already been approved by the JCP, then the continued use of javax.cache.* should be allowed within EE4J.  It's the "net new" technologies that would be incorporated into EE4J that would require an alternate package name.  For example, if a new spec is developed at EE4J -- let's say for NoSQL.  Then, that project would not be allowed to use javax.nosql.*.  This new project would have to use something like org.ee4j.nosql (or whatever is decided).

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn:  <https://www.linkedin.com/in/kevinwsutter> https://www.linkedin.com/in/kevinwsutter



From:        Guillermo Gonz?lez de Ag?ero <z06.guillermo@xxxxxxxxx>
To:        EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Date:        11/13/2017 01:02 AM
Subject:        Re: [ee4j-community] Use of javax.* in new EE4J projects
Sent by:        ee4j-community-bounces@eclipse.org

  _____




Exactly.

It's fine to abandon the Java EE brand and have a fresh start, but Java EE is not only about EJBs and other "heavyweight" technologies. JSON-B is an EE spec that's clearly useful outside Java EE and I hope Jackson and Gson will implement the spec at some point. I doubt that would happen if the package name would be e.g. "org.ee4j.json.bind". I don't think we would have had such a list of Servlet containers if Servlets had been created from an external entity.

JSON-B, JSON-P, JCache, JAXB (not available in Java 9 by default, needs the "java.se.ee <https://urldefense.proofpoint.com/v2/url?u=http-3A__java.se.ee&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=b_vTeQOmwB1585BadfMll-Cc5aCWacnokkUnueEf-qM&s=IsTgAs7QqNr484MafDPam1ZaHxa1Ldkq05ajG1N_TcQ&e=> " module) are good examples of specs I think are totally useful outside Java EE environments. Sure we can expect these existing specs to retain the javax packages, but what will happen with new specs? Will we still need to use the JCP if we want to promote some spec to still be part of the Java library?

We already know Oracle's opinion on this, but now that we already have the PMC set up, I'd like to hear other vendors thoughts and how you think this can be tackled.

Regards,


Guillermo Gonz?lez de Ag?ero

El dom., 12 nov. 2017 a las 22:38, Reza Rahman (<reza_rahman@xxxxxxxxx>) escribi?:
To be clear, the Java EE Guardians community also believes a clean break from the Java EE brand is potentially a good thing. The issue is a largely forced distance from the Java brand as well, not just the Java EE brand. I think it's hard to argue the Java brand is not a good thing to retain.

I think the linked JotForm default text makes the distinction quite clear. The text actually largely describes our community's joint position already. Perhaps it is worth a brief read. There is no need to ultimately submit the form if one is not compelled.

Sent from my iPhone

On Nov 12, 2017, at 4:16 PM, Martijn Verburg <martijnverburg@xxxxxxxxx> wrote:

I'm going to play Devil's Advocate here and say that sadly the Java EE brand is seen as a negative thing.  Unfortunately we were never able to shake off the dire reputation of J2EE, despite the vast improvements to the platform.

I think a clean break is actually a *good* thing.

Cheers,
Martijn

On 12 November 2017 at 18:05, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
I am very glad someone like yourself from the vendor/EC side see this as an issue and is willing to publicly identify this as an issue.

This is by far one of the biggest issues we have identified so far in the Java EE Guardians community. As an initial step, we have asked the community to send Oracle and other key EE4J stakeholders direct and personal feedback on this: https://form.jotform.com/72648425384161 <https://urldefense.proofpoint.com/v2/url?u=https-3A__form.jotform.com_72648425384161&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=b_vTeQOmwB1585BadfMll-Cc5aCWacnokkUnueEf-qM&s=0ao_Pby1v5Snv9D3MzcoMkDetcXBLWKQXYTOB1kx28s&e=> . I suspect it is the sole matter with regards to EE4J that these folks have been reached out to about the most.

Unfortunately clearly the community has still not really been heard on this matter. While I am sure the root cause of this issue is Oracle's legal and branding departments being overly rigid, this is something that Oracle executives can intervene on if they deemed it worthy of solving.

>From the Java EE Guardians community, our likely next steps are to arrive at a joint open letter asking EE4J stakeholders to address this issue - Oracle being the main party of our request. Any support you can lend us in this regard, even if only moral, would be helpful and highly appreciated.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Greg Luck <gluck@xxxxxxxxxxxx>
Date: 11/3/17 2:07 PM (GMT-05:00)
To: ee4j-community@xxxxxxxxxxx
Subject: [ee4j-community] Use of javax.* in new EE4J projects

Hi

Had a call with Mike today about moving JCache across to EE4J.

We have JCache 1.1 in the JCP review process now and it should be out in a few weeks? time. So we could consider moving after that point.

The biggest issue to me is that, at least currently, any new APIs will not be allowed to use javax. Today we use javax.cache. This would mean that JCache 2 would need to change its package name. We have 13 implementations out there and a huge amount of user code that uses javax.cache. This would be an extremely disruptive change.

In our case Oracle is a copyright owner along with myself for the spec. As an owner, Oracle if they wished, should be able to allow JCache 2 to continue to use the javax.cache package even though the process has changed from JCP to the yet unnamed and to be formed Eclipse Community Process.

Interested in anyone?s thoughts on this.

Regards

Greg Luck



_______________________________________________
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=b_vTeQOmwB1585BadfMll-Cc5aCWacnokkUnueEf-qM&s=1aURO5_qrTH4KUGplh6f883VN8ViLWd64OZ9v3qZ5-A&e=>


_______________________________________________
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=b_vTeQOmwB1585BadfMll-Cc5aCWacnokkUnueEf-qM&s=1aURO5_qrTH4KUGplh6f883VN8ViLWd64OZ9v3qZ5-A&e=>
_______________________________________________
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=b_vTeQOmwB1585BadfMll-Cc5aCWacnokkUnueEf-qM&s=1aURO5_qrTH4KUGplh6f883VN8ViLWd64OZ9v3qZ5-A&e=> _______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
 <https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=b_vTeQOmwB1585BadfMll-Cc5aCWacnokkUnueEf-qM&s=1aURO5_qrTH4KUGplh6f883VN8ViLWd64OZ9v3qZ5-A&e=> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=b_vTeQOmwB1585BadfMll-Cc5aCWacnokkUnueEf-qM&s=1aURO5_qrTH4KUGplh6f883VN8ViLWd64OZ9v3qZ5-A&e=




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171113/1c929736/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 3, Issue 26
*********************************************