The Mats3 system itself is fully working all OK on Java 8 and the JMS API 1.1 - and I've tried to stay there to be as nice as possible to users.
However, with ActiveMQ and Aremis moving up to Java 11 and Mats3 JMS implementation and testing tools mainly revolving around these, it becomes annoying to stay down at Java 8. I both need to include non-updating dependencies (ActiveMQ 5.16.6, while it has moved to 5.17/8, Artemis 2.19.1, while the latest is 2.29 - both on Java11), and include some conditional logic based on the version being used. These also utilize the jakarta.jms dependency, instead of javax.jms - which also caused a problem wrt. "auto-upgrade-resolving", check #80.
Wrt. adopters of Mats3: The usage of Java11 is at #1, with 59%, while Java8 is at some 33% - and steadily changing. Also, any new use of Mats3 would most probably be on new projects.
The Mats3 system itself is fully working all OK on Java 8 and the JMS API 1.1 - and I've tried to stay there to be as nice as possible to users.
However, with ActiveMQ and Aremis moving up to Java 11 and Mats3 JMS implementation and testing tools mainly revolving around these, it becomes annoying to stay down at Java 8. I both need to include non-updating dependencies (ActiveMQ 5.16.6, while it has moved to 5.17/8, Artemis 2.19.1, while the latest is 2.29 - both on Java11), and include some conditional logic based on the version being used. These also utilize the jakarta.jms dependency, instead of javax.jms - which also caused a problem wrt. "auto-upgrade-resolving", check #80.
Wrt. adopters of Mats3: The usage of Java11 is at #1, with 59%, while Java8 is at some 33% - and steadily changing. Also, any new use of Mats3 would most probably be on new projects.