Consider renaming resource.cci.Record to avoid collisions with java.lang.Record

[lukasj]

JDK 14 introduces java.lang.Record thus making all usages of *.resource.cci.Record ambiguous even if there is direct import.

[smillidge]

yuk one for Jakarta EE 10

[njr-11]

Thanks for bringing this up. Very unfortunate to have the collision here. If we were to modify a class name in the spec, the ideal place to do that would be in Jakarta EE 9 where there is already churn on the package names. However, I'm pretty sure that Jakarta EE 9 doesn't allow this level of change. I don't think we should burden our users with yet another incompatible change in Jakarta EE 10. Maintaining compatibility for a few releases afterward is going to be really important after what we [were forced to] put our users through in Jakarta EE 9, so my vote is against doing this.

[frowe]

have to agree with Steve and Nathan, this one is not for ee 9. ee 9 is touted as package name change only, this change could break apps relying on JCA. Nathan's comment about doing this at all brings up a valid point, we may be testing users patience with what could seen as unnecessary churn.

[frowe]

I see this was added to 2.1 milestone a while back. If we were going to make this breaking change, it would require a rev of the major spec number to 3.0, right? But, I'll reiterate, I don't think we should make this change in any release.

[lukasj]

if user wants to update (=rebuild) existing connector to SE 14 or newer, he has to update his sources anyway, since the introduction of the Record class broke source compatibility. So to be able to re-build it, one has to either replace all current usages of Record with FQN (imagine a method merging 2 records into one which is returned) OR replace Record with the new name eventually. But yes, the latter option also breaks the binary compatibility.

I see no reason why one couldn't update the project plan should he wants to do this change for EE 10.