[QUESTION] Support for Jakarta namespaces

[Ortofta]

Are there any plans to release a version of the JDBC driver using the "new" Jakarta namespaces instead of the old javax equivalents?

[Jeffery-Wasty]

Hi @Ortofta,

No current plans, and nothing that I can see in our backlog. I'll bring this to the attention of the rest of the team and let you know if this is something we want to eventually include.

[Ortofta]

Thanks, @Jeffery-Wasty.

We are in the process of upgrading our app to Spring 6 / Jakarta EE9 (or 10) - and I assume that your dependencies on for example javax.transaction will be a problem.

[lilgreenbird]

We have put this into our backlog as a future enhancement. Please let us know if you run into issues when you do your upgrade.

[dcaillia]

It looks like i'm stuck on this too (also migrating to spring 6).

java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter

which is now in the jakarta.xml.bind-api:4.0.1 module (the class is now named jakarta.xml.bind.DatatypeConverter).

The JakartaEE9 migration (renaming some javax package names to jakarta) is several years old already. Given there's not much complaints here, i guess people found workarounds that i am not aware of?

[dvaneechoutte]

This becomes quite urgent for us as well. Any progress on this topic?

[Ortofta]

We unfortunately had to pause our upgrade project, but I hope to resume work on it soon^TM - so I too would appreciate an update on what the plans are to support the Jakarta stuff.

[David-Engel]

If someone has already done the research and has full context, can they summarize here what the issue is? Specifically, the answers to these questions, and any other pertinent background info, would help prioritize this ask:

1. What is Jakarta? (I did Google it a bit.)
2. What is the impact of not adding Jakarta support? I.e. What, specifically, does Jakarta support unblock?
3. At a high level, what would the required changes look like in the mssql-jdbc library in order to support Jakarta?
4. What kind of backwards compatibility issues would arise from adding Jakarta support? Or how would backwards compatibility with javax be retained?

[Ortofta]

@David-Engel - I have done some research, but I'm not claiming to be an expert in this,

1. What is Jakarta? (I did Google it a bit.)

Jakarta EE is the continuation of the Java EE specification. The last Oracle version of Java EE was 8, which was released back in 2017. The Java EE specification was then taken over by the Eclipse Foundation for future development. My understanding is that Oracle will not be developing any new versions of the "old" Java EE. I believe there were some dispute over trademarks, leading to the change of package names from javax.* to jakarta.* from Jakarta EE 9 forwards.

See for example Wikipedia, Jakarta EE FAQ

2. What is the impact of not adding Jakarta support? I.e. What, specifically, does Jakarta support unblock?

The impact is that any project using the latest versions of popular frameworks like Spring will not be able to use the SQL Server driver, as they have moved to the Jakarta namespace as of version Spring Framework 6 and Boot 3.0.
Getting Ready for Spring Framework 6

3. At a high level, what would the required changes look like in the mssql-jdbc library in order to support Jakarta?

Identify and replace any dependencies on javax packages and replace them with the corresponding jakarta dependencies.

4. What kind of backwards compatibility issues would arise from adding Jakarta support? Or how would backwards compatibility with javax be retained?

My understanding is that you need to maintain two separate versions if you want to support usage of the driver by both legacy javax and modern jakarta applications. It's not a good idea to mix javax and jakarta dependencies.

Please feel free to correct anything that I've gotten wrong!

[Jeffery-Wasty]

Hi @Ortofta,

Thank you for the reply. We'll look over this issue again after our release and leave a reply with how we're going to proceed with the issue.