[eclipselink-dev] Issues supporting applications written in the javax an

[David Blevins <dblevins@xxxxxxxxxxxxx>]

> Begin forwarded message:
> 
> From: Lukas Jungmann <lukas.jungmann@xxxxxxxxxx>
> Subject: Re: [jakartaee-platform-dev] [External] : Re: Standardizing new TCK packages (was:package prefixes for Jakarta Batch TCK-related classes?org.eclipse.ee4j.batch ?)
> Date: January 10, 2022 at 11:12:05 AM PST
> To: jakartaee-platform-dev@xxxxxxxxxxx
> Reply-To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
> 
> On 1/10/22 7:08 PM, Emily Jiang via jakartaee-platform-dev wrote:
>> The reasoning was mentioned in this mailing list thread as part of conversation.
> 
> I'm sorry but I got lost in the thread at the point where it was said that _some_ implementations are having hard times optimizing themselves. If that is the problem, then, IMHO, implementations should be fixed as they are usually those the best knowing the real "why" for what are they doing. I believe that what they are doing is not correct in 100% cases and  it is possibly just a matter of time till someone files an issue for some of those corner-cases for which the "optimization" is wrong.

I pointed this particular example out twice, moving it here in hopes it might be better seen.

EclipseLink is one of the implementations I pointed out that would most likely not be able to handle users developing applications *in* the javax or jakarta namespaces.

Here are the lines that are suspect:

 - https://github.com/eclipse-ee4j/eclipselink/blob/master/moxy/org.eclipse.persistence.moxy/src/main/java/org/eclipse/persistence/jaxb/javamodel/reflection/JavaClassImpl.java#L390-L392
 - 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
 - https://github.com/eclipse-ee4j/eclipselink/blob/master/moxy/org.eclipse.persistence.moxy/src/main/java/org/eclipse/persistence/jaxb/rs/MOXyJsonProvider.java#L761-L763

I don't know if these in fact do cause issues if someone attempts to create original application code inside the javax or jakarta namespaces.  I do know that when we attempted to use the Eclipse Transformer on EclipseLink these were some of the areas that prevented the new jakarta APIs from working and caused most the JPA TCK to fail (sort of the reverse problem).

I personally don't think it's an issue as people should not be developing their own code and putting it in the javax or jakarta namespaces.  If we allowed TCKs, which contain applications, to use the jakarta namespace, there might be an issue.

If people think this is an issue, I can file it in the Github issue tracker.


Side note, does this class also need to get updated to account for the jakarta namespace?

 - https://github.com/eclipse-ee4j/eclipselink/blob/master/jpa/org.eclipse.persistence.jpars.server/src/main/java/org/eclipse/persistence/jpa/rs/PersistenceFactoryBase.java#L145


-David