Recursive Comparison and JAXB/Java EE

[gigermocas]

AssertJ v.3.25.0 introduced a major breaking change by not allowing classes from javax packages from being introspected (due to #2928). The end result means that all classes on javax packages from Java EE and JAXB (on Java 17), are excluded from being properly asserted on using recursive comparisons.

The most common use case for me is using this feature on JAXB objects, which are by definition can be deeply nested through javax.xml.bind.JAXBElement classes.

I am unable to move to the Jakarta EE 9 ecosystem completely for most of my projects but still would like to take advantage of new AssertJ features and bug fixes.

Is this an intended consequence and AssertJ v3.24.x should be used for those still with dependencies on the javax.* namespace?

[joel-costigliola]

@gigermocas with java version are you using and do you know if Java EE 9 has modules that won't allow reflection ?
In java 17+ we know that we can't introspect java types, I don't know what the state of Java EE is in that regard.

We need to discuss as a team whether to allow introspecting javax types (or having an option to choose whether or not to)

[gigermocas]

From what I understand, java types are detected by class name in AssertJ, in my example, javax.xml.bind.JAXBElement is detected as a java type on v3.25.x., but the package java.xml.bind does not belong to the JRE since Java 11 (I'm using Java 17). I didn't have an introspection warning using recursive comparison on v3.24.x.

Jakarta EE 9 moved the base package from javax to jakarta so I would not have a problem there (see JAXBElement (Jakarta EE Platform API)) as It would not be detected as a java type so It would continue to work as before.

The only other thing that I did when configuring the recursive comparison was to ignore ".*declaredType" and ".*scope fields on JAXBElements due to reflection classloader errors, I would assume that some other types would need some extra configuration if needed. I think that's to be expected.

[joel-costigliola]

I am unable to move to the Jakarta EE 9 ecosystem completely for most of my projects but still would like to take advantage of new AssertJ features and bug fixes.

My understanding here is that with AssertJ 3.25 you have problems as it compares javax with equals but that should not prevent you to migrate to Java EE 9 since the javax packages are moved/renamed to jakarta, is that a correct understanding ?

[gigermocas]

I would not have this issue if my codebase was already on Jakarta EE 9 yes, as the classes I'm using recursive comparison on would not fall into AssertJ's detection of a java type (through the javax namespace).

I was trying to raise a discussion on this point here as it seems to me that the definition of java type as of now is currently too broad and catches more stuff than intended. I was looking for some clarification.