[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] How to name implementation of javax.* and jakarta.* APIs?
|
It's my understanding that the agreement between Eclipse and Oracle doesn't allow the Eclipse Foundation to use many of the older acronyms. What others do is beyond Eclipse or Oracle's control, so while Eclipse will not use those acronyms or promote them, it's going to be a while before the community stops using them. I suspect that bloggers and tweeters will continue to say JMS for Java Message Services as much as they say Jakarta Messaging - at least for a couple of years if not more.
Thanks Mike for this clarification.
We will be interest to knowing if we could use acronyms for future.
For example, JPA or JMS. Jakarta could replace Java . It was spirit of
blog post
https://blogs.eclipse.org/post/wayne-beaton/renaming-java-ee-specifications-jakarta-ee
CDI haven't the word Java in its acronym. Why should we change it ?
A other example is JAX-RS, using a new acronyms will be harmful more
that renaming package.
For developers, he should looking for Jakarta REST (one proposition in
mailing-list) on Internet. He will found no information or little. All
information (Documentation, tutorial, answer) of JAX-RS will be lost.
Regards,
Lilian.
Le 24/05/2019 17:12, Kevin Sutter a écrit :
> Thanks for the insights, Mike! I hope we can now put this package
> naming issue to bed... I'd still like to discuss the use of acronyms
> in documentation -- both Specifications and vendor documentation.
>
> ---------------------------------------------------
> 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 [1]
>
> From: Mike Milinkovich
> <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
> To: jakartaee-platform-dev@xxxxxxxxxxx
> Date: 05/24/2019 09:32 AM
> Subject: [EXTERNAL] Re: [jakartaee-platform-dev] How to name
> implementation of javax.* and jakarta.* APIs?
> Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
>
> -------------------------
>
> On 2019-05-22 4:47 p.m., Bill Shannon wrote:
> I don't think we want to encourage the continued use of acronyms that
> refer to the Oracle technology.
>
> The Eclipse folks know how much fun it has been dealing with Oracle
> legal, and they're the ones in the crosshairs if this is done wrong,
> so maybe they should be the ones to decide just how far this renaming
> needs to go.
> The clear advice that I heard from the Oracle lawyers (and our own)
> was that a namespace such as jakarta.ejb is perfectly fine.
>
> Scott Stark wrote on 5/22/19 1:19 PM:
> When I asked our legal team for their opinion on this, they thought
> the idea of trademarks in package or class names as something that
> should cause confusion and possibly require a trademark license was to
> put it kindly, far fetched.
>
> This is introducing unnecessary technical problems due to name churn,
> so unless Oracle is going to present a legal request that states all
> of the allowed disallowed sub packages under jakarta.*, we are only
> going to accept that the heretofore understood translation of javax to
> jakarta is the only translation that needs to happen at the code
> level.
>
> On May 22, 2019, at 12:48 PM, Bill Shannon <bill.shannon@xxxxxxxxxx>
> wrote:
>
> IANAL
>
> Nothing in trademark law has changed relative to the use of these
> names or acronyms in implementation packages.
>
> My understanding is that if you're using (e.g.) "EJB" in a way that
> references Oracle's Enterprise JavaBeans technology, and you're using
> it in a way that trademark law would consider "fair use", then you're
> ok.
>
> If you're using "EJB" to refer to something this is not Oracle's
> Enterprise JavaBeans technology, and using it in a way that might
> cause confusion in the marketplace, that would be an issue.
>
> We can keep trying to interpret trademark law, and keep looking for
> loopholes, but my advice is to just avoid the issue as much as
> possible and concentrate on more important technical problems.
>
> Scott Stark wrote on 5/22/19 10:36 AM:
> That does not help with nuances that have come up within the
> specification committee with respect to usage like:
>
> 1. In the Big Bang approach, there is an assumption that javax.ejb
> would translate to jakarta.ejb, javax.jms to jakarta.jms, etc. Some
> have indicated that this is not allowed as even the ejb and jms sub
> packages are not allowed to be used. If true, this complicates any
> tooling and compatibility mapping layers.
> 2. A further variation on this is an implementation package such as
> org.jboss.ejb.
>
> Does the Eclipse Foundation have.a view on these uses?
>
> On May 22, 2019, at 4:53 AM, Mike Milinkovich
> <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Strictly speaking the Eclipse Foundation does *not* have a trademark
> agreement with Oracle. We have a copyright license, but have no
> special rights whatsoever to any of Oracle's trademarks.
>
> However, the salient point from my perspective is what I wrote in my
> blog post "Update on Jakarta EE Rights to Java Trademarks [2]".
> In addition to the above, any specifications which use the javax
> namespace will continue to carry the certification and container
> requirements which Java EE has had in the past. I.e., implementations
> which claim compliance with any version of the Jakarta EE
> specifications using the javax namespace must test on and distribute
> containers which embed certified Java SE implementations licensed by
> Oracle. These restrictions do not apply to Jakarta EE specifications
> which do not utilize javax, including future revisions of the platform
> specifications which eliminate javax.
> This means that any Jakarta EE *specifications* that contains even a
> single javax namespace has Oracle-imposed runtime restrictions that
> may or may not be good for the community.
>
> From the point of view of an implementer, I don't think that there
> would be any restrictions on claiming that a single version of Eclipse
> Jetty supports both Jakarta EE 8 (using javax) and Jakarta EE 9
> (perhaps 100% using jakarta).
>
> Does that help?
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev [3]
>
>
>
> Links:
> ------
> [1] https://www.linkedin.com/in/kevinwsutter
> [2]
> https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
> [3] https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
