| Re: [ee4j-community] Use of javax.* in new EE4J projects |
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
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_ qrTH4KUGplh6f883VN8ViLWd64OZ9v 3qZ5-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
*********************************************