| Re: [jakartaee-tck-dev] [jakartaee-platform-dev] [jaxrs-dev] [External] : Re: Jakarta TCK package naming convention |
> On Jan 24, 2022, at 1:36 AM, Jan Westerkamp <jan.westerkamp@xxxxxxx> wrote: > > I think this is a misinterpretation of the spec by you (and others): > > Applications can and in some cases are allowed to use the jakarta.* namespace (or javax.*), especially TCKs are for the last! And this is for very good reason, too (Lukas explained that in detail). Right, as I mentioned on the Platform Dev list, restrictions for app developers (or servers) to not write code inside the javax.* and jakarta.* packages isn't in the specifications, but enforced separately through trademark: - https://www.eclipse.org/lists/jakartaee-platform-dev/msg03051.html (JCP background) - https://www.eclipse.org/lists/jakarta.ee-spec/msg02153.html (jakarta.* trademark references) Secondarily, servers often have code that will handle either javax.* and/or jakarta.* specially and the existence of code like that would prevent applications written inside javax and jakarta from working anyway. Though that was mentioned first, it isn't the primary issue. Myself and Lukas have pointed out that of course applications can contain official javax.* and jakarta.* APIs and implementations, so we would have to be very careful in adding restrictions to specifications or TCKs: - https://www.eclipse.org/lists/jakartaee-platform-dev/msg03057.html - https://www.eclipse.org/lists/eclipselink-dev/msg08204.html I don't think this part has been contested by anyone. > At the moment there is only one platform implementation mentioned in the threads (TomEE), that has problems with that (please add more): That's not correct. I've mentioned this isn't a TomEE thing and at least 15 of our Platform and Web Profile implementations are affected. - https://www.eclipse.org/lists/jakartaee-platform-dev/msg03055.html The only reason I mentioned TomEE is that's the server I know best. Here is some GlassFish code that treats javax specially and could potentially prevent users from writing application code inside javax.* - https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/web/war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java#L3323-L3332 - https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/web/war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java#L116-L117 - https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/web/war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java#L1999-L2003 - https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/appclient/client/acc/src/main/java/org/glassfish/appclient/client/JWSACCMaskingClassLoader.java#L51-L71 - https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/appclient/client/acc/src/main/java/org/glassfish/appclient/client/MaskingClassLoader.java#L113-L130 - https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/codegen/StaticRmiStubGenerator.java#L328-L346 - https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/persistence/cmp/enhancer/src/main/java/com/sun/jdo/api/persistence/enhancer/meta/JDOMetaDataModelImpl.java#L63-L75 I contributed a Java EE 7/EJB/Connector spec feature to GlassFish, but I'm generally not a "GlassFish guy" so I can't say if any of the above would prevent someone from creating application code inside the javax or jakarta packages and have that deploy and work properly. It doesn't matter, however, as 1) application developers cannot develop their applications inside the javax or jakarta namespaces without violating trademark and 2) GlassFish passes all the integration tests we have in the TCK. Certainly, we can add more integration tests where we think they are needed if we feel there are gaps. -David
Attachment:
smime.p7s
Description: S/MIME cryptographic signature