+1
And for the record, rather than try to convince Oracle (legal) to allow javax for net new specifications in EE4J, which several of us have done already, I would much rather we spent our collective time more fruitfully engaged in driving EE4J forward in other areas.
Mark.
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/kevinwsutterFrom:
Guillermo González
de Agüero <z06.guillermo@xxxxxxxxx>To:
EE4J community discussions
<ee4j-community@xxxxxxxxxxx>Date:
11/13/2017 01:02 AMSubject:
Re: [ee4j-community]
Use of javax.* in new EE4J projectsSent by:
ee4j-community-bounces@xxxxxxxxxxx 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üeroEl 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, MartijnOn 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@xxxxxxxxxxxSubject: [ee4j-community] Use of javax.* in new EE4J projects
HiHad 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. RegardsGreg 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=
_______________________________________________ ee4j-community mailing list ee4j-community@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-community
--- Mark Little
JBoss, by Red Hat Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork. Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873 Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
|