Are you interested in contributing or sponsoring this feature (note: we can’t drop javax support either)?

Also, I'm a bit puzzled here. Unless I'm mistaken, the actual ConnectionFactory class you need is the one supported by your actual JMS client library (IBM MQS and friends). Springboot might be providing adapters, but still, unless you're using an updated client, you still have the old javax classes in your classpath.
And I really wonder how many JMS users have upgraded their JMS broker to move to the new "Jakarta EE" stack.

We'll most likely do this move someday, but when there will be enough demand for it.
As of today, you're the only OSS user to request it, and none of our Enterprise customers did.

@matzalew any update regarding the first part of my message? Were you able to find a workaround and use the "old" package?

Sorry, missed your messages.

Did not found workaround.

I could try to contribute. But never done such thing, and I got likely limited time after my working hours. So no promises - but I'd like at least to try.

Hmm not sure how to tackle this. The only idea I have is to basically duplicate everything, and change the import when necessary, and use a different package:

Normally other libraries create two releases. One with javax and one with jakarta. This makes the duplication unnecessary. e.g.
gatling:3.10.4
gatling:3.10.4-jakarta

although I would like the other way around more:
gatling:3.10.4-javax
gatling:3.10.4

@slandelle any progress on this? I would think since they are different artifacts you just have different artifact names. you can add the one you want as a dependency or exclude the one you don't want. I don't see a problem having the package names different. The interfaces for each are in different packages anyway.

This is blocking us on upgrading a library we use has switched from javax.jms to jakarta.jms 3.1.0

Let me know if you don't plan on continuing on this and I'll give it a shot.

@BusyByte Not a priority for us atm because:

• no customer demand, all our Enterprise customers who have a demand for JMS are still using a javax version.
• after only a quick glance, I couldn't find a way that would not boil down to duplicating the whole code, which I'm very reluctant to do

Such a stupid move from Oracle lawyers 😡

@slandelle I've create an initial pull request. My initial thoughts on re-using code is it may require additional abstractions which would require a major version bump. If you just allow the duplication then you can address that in the next major version.

I'll take a closer look at the code next week if I get time. I'm changing roles next week so it may be a month or so before I get back to this.

One issue with my pr is you can't have both activemq brokers in the same classpath so I didn't add it to the docs.

Another solution would be to do some sbt machinery to create alternate modules whose sources would be generated from the javax ones with some regex replacement and file mapping to change the packages and imports.

This would completely remove the code duplication, but wouldn't work if we have to dead with API differences between the javax and the jakarta versions. @BusyByte Are you aware of such differences?

@slandelle I believe it depends on which version of the jee spec you are targeting. While they seem pretty similar to me today other than the namespaces and which activemq distro you pick for an implementation they could diverge over time as the jakarta jee spec continues to evolve but the legacy one will stay the same since it's been removed from the jdk in newer versions. If you look at the Jakarta JMS you can see there are already different major versions EE 8, 9, and 10. I believe the prior release of 2.0.2 is more of the compatibility guarantee version with javax stuff and since then things have diverged already. I'm not sure how much the messaging interfaces change vs other EE stuff. I would assume between 2 and 3 major versions something has changed which is meaningful.

Jakarta JMS 2 is merely changing the maven coordinates. No change inside the jars, the Java package is still good old javax.jms.

Jakarta JMS 3.0 is mostly changing the Java package to jakarta.jms and some annotations and javadoc fixes.

Jakarta JMS 3.1 is just raising the Java version to 11 (which Gatling also requires).

So I think the code generation strategy would currently work and it would not involve any code duplication burden.
I also think it will keep on working in the future. I don't expect a JMS 4 with new features to ever happen. And if I'm proved wrong some day, we'll see then.
As a result, I really think it's the best solution.

Would you be interested in exploring a PR for this strategy?

@slandelle I've been working on this in my on call rotation which won't come back around for a while as this is a maintenance issue for us. If you have some guidance on how to do this I can try but I only get a week at a time and busy with other stuff as well. If you are willing to deal with it taking a while then I'd be more than glad to give it a shot.

As I said, this is not a priority for us atm as there's no customer demand for it so far. So no rush, take your time.