| I like it. How about this as a tweak to broaden it a bit?
"The packages java, javax, and jakarta are reserved and trademarked. Applications should not create or modify classes under these packages. Applications that do so will have unspecified behavior and may not deploy, function properly at runtime or be portable."
I think the statement needs to go one step further and state:
"Applications that do so will have unspecified behavior when attempts are made by the platform to load and process such classes."
But I would like to see this added to at least the Platform specification.
Tom
----- Original message -----
From: "David Blevins" <dblevins@xxxxxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Standardizing new TCK packages (was: package prefixes for Jakarta Batch TCK-related classes? org.eclipse.ee4j.batch ?)
Date: Thu, Jan 6, 2022 2:51 PM
Agree adding something to the specifications is a good idea and very reasonable thing to do.
We could potentially expand the mandatory boilerplate at the start of each specification with something like:
"The packages java, javax, and jakarta are reserved and trademarked. Applications should not create or modify classes under these packages."
We could have it so that the above could be mandatory for all specs going forward. If spec teams (including the platform spec) want to go a few steps beyond that and define how the failure should look, etc. hat's also reasonable.
The only trick to actually rejecting applications that have java, javax, or jakarta in them is many applications include javax libraries in their wars. In my experience most app servers and servlet implementations will tolerate/ignore that to different degrees. With Tomcat for example if you have javax.servlet as an API jar in your war, it's not going to work. However, Tomcat will tolerate javax.xml.rs, javax.ejb, javax.persistence, etc as they aren't shipped by the server and don't conflict. In early versions of TomEE including those would result in failures at runtime. Later we modified the classloader so those would simply be ignored as it became clear other servers were doing the same and facing issues porting to us.
That statement really proves your point.
What do you think about having a standard "don't do that" statement at the top of each spec as mandatory with an option for spec teams to go further as they have time/energy?
Would something like that go far enough?
--
David Blevins
Edicts and trademarks may be clear. What is not clear is what an application classloader/scanning should do when a customer application violates said edict or trademark. If we have many of our implementations defining some behavior based on this then I think it is in our best interests to make it clear in the specification. The only exception that I think is covered is the java.* package because an application class loader needs to do some unusual things to be able to actually define a class using the java.* package (and I'm not sure it is even possible on modern Java versions).
Tom
----- Original message -----
From: "David Blevins" <dblevins@xxxxxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Standardizing new TCK packages (was: package prefixes for Jakarta Batch TCK-related classes? org.eclipse.ee4j.batch ?)
Date: Thu, Jan 6, 2022 11:05 AM
There is an edict that no one should put code under the java and javax packages unless it has been approved by the JCP process. I don’t think that is stated in the resulting specifications, but enforced separately through trademark.
I’m not sure we have a clear rule of our own for jakarta.* (we might), but it would make sense and is likely something we should explicitly document. Possibly in our JESP.
I know we have a doc that says the package must be jakarta.*. I don’t recall if it specifically calls out it is forbidden to use it unless going through the JESP process.
-David
I understand the implementation concern and we certainly should use that to influence our decision if it makes life easier for current implementations. After all, the actual tck package name we chose is not that important in the end. Just need to pick a consistent one, which we own, in my opinion.
All this is not to say I think we must chose jakarta.tck as the package name. For the sake of current implementations is sounds like we shouldn't. But I also think it is a slippery slope to continually make such decisions on something that is so unclearly specified. In the end we can make our decision to not use jakarta.tck because it helps our existing implementations. Not because it is written in the specification as some restriction. If we want to base our decision on the actual specification then I think the specification really needs some work to make it more clear.
Tom
----- Original message -----
From: "Emily Jiang via jakartaee-platform-dev" <jakartaee-platform-dev@xxxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: "Emily Jiang" <emijiang6@xxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Standardizing new TCK packages (was: package prefixes for Jakarta Batch TCK-related classes? org.eclipse.ee4j.batch ?)
Date: Thu, Jan 6, 2022 4:17 AM
Thank you David for the detailed explanation! I now understood the concern.
The following package name might work:
-- tck.jakarta.<spec>.
In all, we could choose one from the list
org.jakartatck.*
ee.jakarta.tck.*
tck.jakarta.*
Thanks
Emily
I think I finally see what Romain is talking about.
I know in TomEE we have several optimizations to try and speed up deployment and bytecode scanning. We'll filter out jars that match patterns like log4j-*, openejb-*, jakarta-*. Those jars are removed from the list of jars that could potentially contain applications and they'll never be searched for annotations like @Singleton, etc. Additionally, as everyone uses somewhat expensive bytecode readers like ASM to parse bytecode and scan for annotations, we have additional filters to skip non-application classes, such as javax.* and jakarta.*. There are classloader related actions as well.
Here's an example we hit in EclipseLink when we tried to use the Eclipse Transformer to do the javax-to-jakarta change.
- https://github.com/eclipse-ee4j/eclipselink/blame/master/jpa/org.eclipse.persistence.jpa/src/main/java/org/eclipse/persistence/internal/jpa/deployment/JavaSECMPInitializer.java#L345
We were transforming EclipseLink 2.x which did not have the `!name.startsWith("jakarta.")` string check, so jakarta.* classes were getting loaded as application classes and causing most tests to fail. We hit this in a few different libraries and ended up having to patch source to ensure "jakarta." and "Ljakarta/" were factored into any code that checked for "javax." as a package or "Ljavax/" as bytecode.
If we started putting the TCK tests in "jakarta.tck" and that also included the test applications we need to deploy and verify, that definitely will cause issues in a handful of component implementations we all use.
The only way to handle it would be to update code like this to have an exclusion that explicitly checks for "jakarta.tck" and ensures it is treated as user-created application code and bypasses any "javax" or "jakarta" checks. That's going to mean there'll be code in our implementations that says essentially "if your code starts with jakarta.tck, make sure it's treated correctly, otherwise do something else." That could be a slippery slope.
It's probably better if we don't put ourselves in a situation were we have to write code to specially handle TCK applications.
It occurs to be in writing this that literally any characters before "jakarta" solves this issue. If we want a short name, we do own the jakarta.ee domain and can potentially use either of these:
- ee.jakarta.*
- ee.jakarta.tck.*
I also just looked and jakartatck.org was available, so I purchased that and we could potentially use:
- org.jakartatck.*
If we wanted to go that direction, I'd just transfer jakartatck.org to the Working Group like I did when purchased jakarta.ee.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jan 5, 2022, at 1:19 PM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
>
> Just to make sure I understand you. Are you suggesting that an application class loader for the old Java EE (e.g. Java EE 8) must not allow not allow an application (WAR) to package and load any classes from javax.* which they contain. For example, no application server should allow an application to contain and successfully load javax.foo.Bar? And now that we are in the jakarta.* namespace no application server should allow an application to package and load a jakarta.foo.Bar class? What about javax now that we are jakarta, can applications in Jakarta 9 now successfully include and load javax.foo.Bar?
>
> I have to say this is news to me, and I do not believe that is the way most application servers behave.
>
> Tom
>
>
>
> ----- Original message -----
> From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
> Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
> Cc:
> Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Standardizing new TCK packages (was: package prefixes for Jakarta Batch TCK-related classes? org.eclipse.ee4j.batch ?)
> Date: Wed, Jan 5, 2022 2:09 PM
>
>
> Le mer. 5 janv. 2022 à 20:37, Thomas Watson <tjwatson@xxxxxxxxxx> a écrit :
> > If you want one example, servlet 10.7.2 (for v4.0 to take one example) explicit it and for good technical reasons so it is a "must stay" but it implies TCK shouldn't reuse the same package by design and as it always had been so it let you org.eclipse for projects without an historical package (guess it is more than fine to keep the existing one when it is there).
>
> In no way do I see how that section of the v4.0 servlet spec says anything about jakarta.*. That package didn't exist in v4. For v5 we have: https://jakarta.ee/specifications/servlet/5.0/jakarta-servlet-spec-5.0.html#web-application-class-loader
>
> Here I think you are referring to this sentence:
>
> "Servlet containers that are not part of a Jakarta EE product should not allow the application to override Jakarta EE platform classes, such as those in the jakarta.* namespaces, that Jakarta EE does not allow to be modified."
>
> TCK classes are not considered platform classes, they are TCK classes. I don't see how this sentence applies to a possible jakarta.tck package.
>
>
> This is true for part of the tck but most of them are *applications* (servlet for a trivial example, everything in war/ear for another one).
> Just stated what we have and do - and to be honest it is normal otherwise tck wouldnt validate compliance using a custom packaging ;).
>
>
> Tom
>
>
>
> ----- Original message -----
> From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
> Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> To: "Emily Jiang" <emijiang6@xxxxxxxxxxxxxx>
> Cc: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
> Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Standardizing new TCK packages (was: package prefixes for Jakarta Batch TCK-related classes? org.eclipse.ee4j.batch ?)
> Date: Wed, Jan 5, 2022 10:09 AM
>
>
>
> Le mer. 5 janv. 2022 à 16:37, Emily Jiang <emijiang6@xxxxxxxxxxxxxx> a écrit :
> @Romain Manni-Bucau
> I must have misunderstood your question. Let me try again to clarify this:
> 1. what's the plan about the spec saying jakarta.* should be excluded from the applications (which means it cant be used by TCK)?
> I disagree with what you said jakarta.* can't be used by TCK because TCKs are part of specs and do not fall into the application category. Besides, can you point out which spec has this sentence? We need to discuss this further to see whether it is correct to say so if it does have this sentence.
>
> Ok so the consequence of you statement is that there is no application code in TCK, no CDI bean, no EJB, no servlet, no JSP etc... (which is not true right?) so TCK are mainly a) application code and b) test code (sometimes c) runner code but let's integrate it in b)).
>
> If you want one example, servlet 10.7.2 (for v4.0 to take one example) explicit it and for good technical reasons so it is a "must stay" but it implies TCK shouldn't reuse the same package by design and as it always had been so it let you org.eclipse for projects without an historical package (guess it is more than fine to keep the existing one when it is there).
>
>
> 2. What about user confusion? "not care" :(?
> Not sure what user confusion do you mean? TCKs are pretty much for implementers. Besides, I am not sure what confusions you are referring to. I think the namespace with jakarta.tck is clearer as it means the tck classes from Jakarta.
>
> As soon as you get the dependency in a dependency - you are an user by definition - then you can get issues if you use jakarta.
> It is also the case for end user - who never use tck package - on maven if they are released under jakarta groupId so as recommended in java ecosystem the groupId should be aligned on the package base name so likely use org.eclipse.jakarta.spec or alike. The risk is users start importing tck instead of the spec and application will work cause the spec comes transitively but it is not what jakarta wants, right? Making it clean is trivial and consistent with everything so I think it is worth not trying to be more clever than we need to.
>
> HTH
>
>
>
> On Wed, Jan 5, 2022 at 3:02 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
> @Emily: i know TCK are part of the spec as well as the API, javadoc and textual doc (pdf/word) but you didn't solve the 2 issues I mentionned (not even speaking of the inconsistency between the status and naming which is something very few will care except eclipse itself maybe) so not sure how the fact it is delivered as a whole solves the fact it is forbidden by spec to use this package.
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
> Le mer. 5 janv. 2022 à 15:26, Emily Jiang <emijiang6@xxxxxxxxxxxxxx> a écrit :
> Romain,
> TCKs are part of spec, as spec includes api/spec doc /tck.
> Thanks
> Emily
>
> On Wed, Jan 5, 2022 at 1:48 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
> @Emily: what's the plan about the spec saying jakarta.* should be excluded from the applications (which means it cant be used by TCK)? What about user confusion? "not care" :(?
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
> Le mer. 5 janv. 2022 à 14:31, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :
> We discussed the various package names including org.eclipse.*. The feedback is that TCKs should align with the corresponding spec. It is much nicer to start with jakarta.tck to denote the TCK classes and also easily to filter out with pattern matching when searching for api classes. Besides it is much shorter than org.eclipse.jakarta.
> In Jakarta Batch Tcks, you will use jakarta.tck.batch instead of org.eclipse.jakarta.tck.batch.
>
> Thanks
> Emily
>
> On Wed, Jan 5, 2022 at 8:05 AM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
> As written on jbatch list I think it is normal and safe to use org.eclipse.<something like jakarta.spec or just spec> since jakarta specs are eclipse projects. It also has the advantage to not use jakarta.* package which is treated specifically by all implementations (by spec actually ;)) and would need some specific rules in the impl is used for tcks too which is not the target of the spec at all. Lastly it makes it obvious it is not part of the API for users so it is very good too. For me, it looks like a consistent and good compromise for everyone (foundation, users, vendors and spec contributors/legal).
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
> Le mer. 5 janv. 2022 à 08:23, Jean-Louis Monteiro <jlmonteiro@xxxxxxxxxxxxx> a écrit :
> Sounds like a good improvement to me as well
>
> Le mar. 4 janv. 2022 à 22:00, David Blevins <dblevins@xxxxxxxxxxxxx> a écrit :
> > On Jan 4, 2022, at 12:23 PM, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
> >
> > I had this matter discussed in today's platform call. Below is the suggestion for the naming convention:
> > • [Emily] Package naming convention for TCKs?
> > • Packages for TCK starts with various names, e.g. org.ibm, org.jboss, org.eclipse, jakarta.[spec].tck etc,
> > • Should they be standardized?
> >
> > • Two things need naming standard:
> > • Packages
> > • Suggested Naming Standard: jakarta.tck.[spec]
> > • New classes in existing TCKs should use the new name standard
> > • Artifacts
> > • Same group id as the spec
> > • Artifact ids [foo]-tck
> > • Existing TCKs may change if they like
> > New TCKs must use the new name standard
> >
> > The above is the general consensus from the meeting. I will start a new thread conversation for others to comment on the naming convention.
>
> Others can chime in, but I like the above recommendation. Using jakarta.tck.[spec] is just as good as org.eclipse.jakarta.tck.[spec], perhaps better.
>
> Also agree that it should be standard across the various TCKs.
>
>
> -David
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
>
> --
> Thanks
> Emily
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
>
> --
> Thanks
> Emily
>
>
>
> --
> Thanks
> Emily
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
Sent from Gmail Mobile
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
