Migrating ActiveMQ to Jakarta EE - JakartaOne Talk
Video Summary
Matt Pavlovich discusses the migration of Apache ActiveMQ to Jakarta EE at the recent JakartaOne Livestream 2024, emphasizing the challenges of dealing with a mature, widely used codebase. He outlines a two-step approach: first, reducing technical debt in a pre-Jakarta release (ActiveMQ 5.18), and second, introducing Jakarta EE features in a parallel release (ActiveMQ 6.0). Key changes included adopting JMS 2.0, upgrading to JDK 17, and transitioning to Jetty 12. Metrics for observability and multitenancy were enhanced, and virtual threads were added in a technical preview. The migration involved over 100 commits, dropping two Maven modules, and re-homing two dependencies. Future plans include further performance enhancements and potential Spring-free configurations.
The entire, nearly six hours, JakartaOne Livestream 2024 conference is available on YouTube by clicking on this link.
Video Contents
In this session, I want to share my experience in migrating ActiveMQ to Jakarta EE. So let's jump in. Just a brief introduction about me in some of the areas and projects that I've been involved in short, been working for most of my career, helping large enterprises implement open source as part of their infrastructure, whether it's the Linux operating system or all the way up through middleware stacks. But for the most part, you know, as it relates to this talk, I'll be talking from my contributions with the Apache ActiveMQ project. I'm a PMC member and Committer, and I led the the effort to convert ActiveMQ to Jakarta.
I'm sure you guys all been on the stream all day so, but just for just to recap quickly, if people are wondering, what is Jakarta EE. Essentially what it is, it's a group of APIs that sit on top of Java to enable enterprise type development and with the new licensing structure, similar to how the JDK has been freed from, you know, unfriendly licensing. Now these enterprise APIs have been also freed up. And as part of this, the transition, we've got to do a little bit of namespace changing. So everywhere in your Java code where you saw import javax essentially, you're now going to just write as import Jakarta JMS, right? As easy as that, hopefully, as it turns out, with a big and mature code base, things can be a little bit more complicated than that, so that's what we're going to talk through in this talk.
So as an overview, ActiveMQ is the most widely used Message Broker in the world. With a very mature code base, it has over 30 Maven modules. This covers a wide range of Jakarta EE. And so the purpose of this talk is talk about strategies and approaches and the lessons learned that we applied while converting ActiveMQ to Jakarta EE with the idea that if in your enterprise, if you've got large, mature code bases that also need to make the transition that some of these strategies, approaches and lesson learned would help you, in your your organization, make the same transition successfully. So from an involvement perspective, you know, the reason we're involved in my the job, my job that pays the bills is on the co-founder and CTO of HYTE, ActiveMQ powers the Message Broker inside our platform, and we build a platform on top of ActiveMQ that provides Kubernetes based deployment, self-service, and we're driving towards Queue-as-a-Service capability for message queues. And we've developed a bunch of advanced features on top of ActiveMQ, including things like full search, import, export, auto rebalances, many others. And we led, you know, us at high we led the ActiveMQ migration to Jakarta EE, and we're the driving force behind a lot of the neat, neat new feature developments in ActiveMQ. So that's how we got involved with ActiveMQ, and why we're we're still engaged with the community.
Okay, so let's jump into jump into the migration area. So I think it's helpful to kind of think of this as you know, at the very beginning, first slide, we're like, hey, let's just do a bunch of search and replace, and you're done. But when you have a mature code base, you're always dealing with, where is that code base? What point in time is that code base as it relates to the larger ecosystem? So, you know, no matter where you are with your your enterprise application, there's, there's going to be some level of technical debt. You know, if you haven't updated in two weeks, there's probably a dependency that needs to be updated. Mature code bases have been around for a dozen or more years. You'll be looking at JDK build tool updates. And then lastly, we can talk about, you know, some of the Jakarta API impacts. And so I think it helps to think about the problem breaking it up into these three areas. And we'll discuss how we attack that with ActiveMQ.
So technical debt, this is the big thing. The catch here is most of the work in in making a migration really has to do is tackling any any technical debt that's piled up. So especially with ActiveMQ jumping straight to Jakarta wasn't really realistic, because it accumulated some technical debt. And also ActiveMQ is really widely adopted, not only as a server like messaging and infrastructure layer, but it's also embedded and used in a lot of other open source and commercial products to an embedded unit test and integration test, because it's used very extensively as well for other applications to certify their JMS support. So taking something that you think is just server side and okay, we're going to flip the switch and jump to Jakarta, it's just not realistic. We had to be really mindful that making these changes was going to break a lot of people's not only back end infrastructure or had the potential to break infrastructure integration and unit tests as well. So we want to be mindful of all those things.
Secondly, the big the big update that ActiveMQ had in the technical debt areas is, well, ActiveMQ has long been the bearer of the JMS spec standard. It's been very good in that area, and many people, like I said, use it to certify their their products for JMS compatibility. There's a big feature that was those added in JMS 2.0 that ActiveMQ, for a long time, didn't really bother with, and the reason was because there was a better feature known as virtual topics, which was much more flexible and useful than that key feature, the the shared topic subscriptions. However, once it once we started looking at, okay, we need to move over to Jakarta, it really became clear that it was going to be impractical. Just to continue that approach, we really needed to bite the bullet and and start adding the JMS 2.0 features. And so that was a big piece of the technical debt that ActiveMQ needed to tackle. So to do that, what we did is we settled on an approach that, essentially, we'd create a, we'd level up where, where the code base was from a technical debt perspective, and we would jump all that up to something current, and we would have two release strings running simultaneously. So we could have a pre Jakarta, essentially a pre Jakarta release that was going to we're going to level up and clear up as much technical debt as possible. And then we'd start on the Jakarta changes in a new release. And so those became ActiveMQ. It's the 5.18 series, so that has optional client side Jakarta EE support. So most applications that work with ActiveMQ use it as a client. They use it to send and receive messages from their message queues or topics. And so the idea here is this would be a low impact change for applications that needed to quickly start adopting Jakarta, we could provide a client library without necessarily having to have the server side done, because most the bulk of the lines of code change and all that was really on the server side. So the ActiveMQ 5.18 release served as kind of that, that bridge. We leveled up the technical debt, and then we provided this optional client side Jakarta client library. So while we were working on the server side, applications could start, that were client only, could start consuming that new, basically that new client jar in a Jakarta environment. Additionally, we wanted to have some key project goals. So while these two release streams are going we want to make sure there's compatibility is maintained between client and servers, even if they have a mix of the non Jakarta or the Java xjms and the Jakarta JMS. So you could use a 5.17 ActiveMQ jar and talk to a 6.0 broker, or vice versa, you could use a newer jar and talk to an older broker. So this is going to help alleviate the stress in place that if applications need to update, it's not going to force the infrastructure, because that starts dragging and forcing organizations to have to upgrade completely, entirely across the organization that that we don't we didn't want to tightly couple client to broker change, because that that would force your whole environment to change at once. So this is a really, it seems like a small, subtle thing, but in organizations that have large deployments or lots of applications in integration space, this is a really big thing to be able to support mixing Jakarta and non-Jakarta at the same time, because we're not forcing everybody and all applications to upgrade at once.
Secondly, we want to really as best possible. We want to maintain the ability to backport changes going forward between these two releases. So for example, in the six series, we started adding more features around observability, performance metrics, things around improving the quality of capability for multitenancy. So any of these cool new features that we wanted, we also wanted to have the ability to backport them, so without everyone having to be, you know, major git ninja, we want to keep those commits manageable to where we could back port A lot of these cool features. So as much as possible, we wanted to keep the word Jakarta kind of behind the scenes. So if we had a new feature, we could plug that in and move code and security changes from 6.0 back into the 5.18 and so it's a big, a big win for us. So really, this is the big aha moment. Was we were going to maintain two release streams, a leveled up, reduced technical debt version that's pre Jakarta, and then the Jakarta based version in six.
So just on a deep dive, this was a really, I think, a novel approach, and this, this would apply not only for code bases that are making the change to Jakarta, but also for code base. Is that need to support moving APIs, even if it's your internal application. So what we did is on the in the 5.18 series. So we wanted to be able to provide both javax and Jakarta support. So we had a new module, which was just the activemq-client-jakarta.jar. So applications that needed to start using Jakarta APIs, they could pull this jar in specifically and start consuming ActiveMQ on a client basis, as in a Jakarta environment against a non-Jakarta broker. And to do that, if you remember earlier we talked about we had to start adding JMS 2.0 features. Well, we didn't want to tightly couple all that work. It would have been too much. And then in the open source world, it's hard to get all those votes, to get all the approvals out. So we wanted everything very incrementally. And so what we did, the novel approach here, was by implementing this new module, it being new, we're not breaking semantic versioning. We could start adding those new methods, one at a time during point releases. So the very first jar that went out, all the new JMS 2.0 methods just simply threw an unsupported operation exception. So that worked. This, this create a novel approach. So if you're using the jar and you're using it essentially a JMS 1.1 way, you're not going to have any problems. It's all just going to work. Once you want to start using JMS 2.0 operations, you'd have to really make sure that it was ready for you. And as we started adding JMS 2.0 operations, we would start filling in the implementations on a method by method basis, and removing those areas of code that we're just throwing on supported operation exception. So this is a really neat way. So if you look at kind of on a big picture, like project management, Product Owner perspective, we were able to do a couple things at once without breaking clients and without tightly coupling applications to infrastructure and then infrastructure to all the other applications that tied to talk to that same infrastructure. So really, really neat that some of the you know, the simple, novel approach that approaches ended up working out really well
In 6.0 really, the big story here is that ActiveMQ 6, that's the Jakarta support on the server side. Eclipse jetty. The Jetty infrastructure provides the HTTP services. This was the really big update in ActiveMQ. So when we make the change to jetty, not only did it was there namespace changes, but there were also code implementation changes. The way Jetty worked essentially changed between the versions 9 and 11 that we moved to. Unfortunately for us, Jetty did something really, really cool. And I think other platforms, I wish other platforms, I wish we had done this really, with ActiveMQ. Is after we started the work on ActiveMQ, Jetty made a release change that what Jetty 12 does is Jetty 12 supports both javax and Jakarta at the same time. So if you were to upgrade and adopt Jetty 12 today. You could do what we're talking about with a lot less headache, and we're having to do kind of one more upgrade from 11 to 12. So if you haven't started this is you're going to be your big aha moment to skip some pain. Just jump straight to Jetty 12. And you can do this two releasing, to release stream strategy with a few less headaches. So yeah. So we started the work on Jakarta, but it was before Jetty 12 was released. Jetty 12 did this great thing that you know allows you to do both Jakarta and non-Jakarta or pre-Jakarta APIs. Just from on a side note, Jetty 12 support is underway in ActiveMQ. We're in pull our, the pull request for that's in progress. I think there's a couple minor things that need worked out. And it'll be integrated into a future ActiveMQ 6. And it may be back ported. If we back ported it on the 5 side. That work, it would have to be a new it'd be like a 5.19 or 5.20 type deal. You know, there's no firm plans on that, but that would be something that we could potentially do with both our both active release streams at the same time.
ActiveMQ, One of the things ActiveMQ uses, it uses spring to kind of wire all of its components together. And making the jump to Jakarta meant making the jump to Spring 6. When you make the jump to Spring 6, you also drag a Java JDK 17 requirement, because Spring 6 requires JDK 17. So we also had to level to 17, which is not a big deal. We want to be moving forward with JDKs as well. But what this meant is, with infrastructure products like databases, message queues. You often like to be you often like to have the client code be current, but go be able to go back a couple JDK layers. You know, as you know, big enterprise infrastructure tends to move a little slower. You know, glacially is sometimes a term used. It would have been nice for ActiveMQ to be able to support JDK 8 or 11, a little bit longer with the with the Jakarta, but the Spring 6 dependency, you know, forced, force it into a JDK 17 world. So not a big deal moving forwards better anyway. You know, maybe we'll drag some enterprises up with us as well. Most of the JDK 17 changes were minor. We did separate them into separate commits to keep things backport friendly, Maven and other tool chain updates weren't a major issue for us when we're talking about leveling up your technical debt and your projects. That's one of the easiest things to start trying to move forward is the JDK in your tool chain, in your integration layer. So definitely recommend moving forward with those pieces where you can early
Jakarta EE changes, right? Super easy. We're just gonna search and replace and be done, right? No, you know. And I think the cool thing about what's happening with Jakarta is now, like the JDK is getting all these really cool new features. It's coming at a really nice, a good, consistent pace. Now we're we're going to start seeing this with the or we are seeing it with the Jakarta API. So now we're seeing really good and long needed features coming to these enterprise APIs that are used across the board. So we're excited about it in general. ActiveMQ, the Jakarta API is there that are in scope here, obviously Jakarta messaging, previously known as JMS, servlet, transaction and XML. And then there was one JD, J2E spec that was actually dropped. So this spec was in the J2E world that did not come across or come over when, when the Jakarta change was made. So there is no Jakarta management spec anymore. So we dropped that. And the way we what we did with that is we essentially had to just what this spec used, was used for, is metrics and tracking, like statistics. So kind of like a pre micro meter type deal where you can have metrics that sample and keep track of what time the metrics came in, things of that nature. So we went ahead and just what we call the self hosted those interfaces and those classes, so no longer. So we basically rip off the implements statistic and we made our own interfaces and just self hosted them and went that route. So not a lot of APIs. I think there was maybe one or two or maybe three in the that didn't make the jump from J2E to Jakarta, but most of these aren't widely used, so wasn't a big deal.
Managing dependencies, yeah. Overall, this could be a talk by itself. We're, you know, I'm personally a big fan of less is more when it comes to dependencies and really following those talking about how to manage, especially in the enterprise space, when you're dealing with hundreds and 1000s of integrations or 10s of 1000s of applications, the those cross cutting dependencies can be really problematic. So, yeah, definitely less is more, especially when you're supporting two release streams. So you've got your pre-Jakarta release stream going in your Jakarta release stream going. It can be tricky to have and manage, you know, and a lot of this is about trying to be able to back port from your Jakarta back into your pre-Jakarta. So less is more when it comes to it. A lot of the libraries, you know, if you've been doing Java a while, a lot of these libraries have now, there's a lot of new, nifty JDK built ins, alternatives to things. So definitely look at those, the NIO libraries for files, the concurrence all the new collection, obviously the time libraries, things of that nature, try to use those as part of it and start dropping some of these dependencies. It's kind of rough to pull in a whole two or three libraries if you're using four methods out of it right self hosting sometimes can be better. Also, if you've got a bunch of simple util based functions you know that you're using, like formatters and string formatters, time formatters, those are great candidates to be converted to lambdas and things like that. So leverage the language. You know, the JDK is moving rapidly. It's it's great. And then the less dependencies you will have, the easier it is going to be maintained your long term Jakarta based code base, but also moving between the Jakarta and the pre-Jakarta. We had two dependencies. We had to re-home, stompjms and joram-jms-tests. These were open source projects that the kind of the main the maintenance on it kind of stalled out and staled, went stale. So instead of trying to get those ramp back up, we took the approach of just self homing these, or re-homing those back into the ActiveMQ main tree. Both of these were really just used as test dependencies anyway, so it wasn't a huge deal or anything that was blocker would impact. None of this would have impact like downstream application users, most people will never know this happened. The one of the things we had to make a decision on with the first release of 6.0, is we had to drop support so ActiveMQ bundled a couple other downstream components, specifically Jolokia, which provides a HTTP based or REST based view into like JMX management beans for querying metrics and statistics. Jolokia didn't have a Jakarta based release at the time when we released 6, so we temporarily dropped support for Jolokia. Same thing with Apache Camel, but both of those now have their Jakarta based releases. So Jolokia has already been reintroduced, and I believe Apache Camel's going to be shortly, but just that was really more of like a time frame thing where we were ActiveMQ is a framework or as an infrastructure piece. You know, when we we started the change, it was, you know, kind of midstream in the in the Java ecosystem. So everything we really needed had already been converted. And a couple of these things that were were tack ons, it was okay for us to release and then bring them back when, when those were ready. Now, if you're doing your enterprise, I expect you'll be in good shape. Everything you need is should be Jakarta-fied.
All right, recommendations, best practices and approaches what works the migration two step, create that pre Jakarta EE stable release version, pay down as much technical debt as possible. And then secondly, create a new JEE based major version release stream to run in parallel. The main thing here is, is you want this pre Jakarta EE release? Because if you're, if you're, especially if you're in an enterprise in which you have is like frame in the framework E or platform or on the edge of framework or platform E, kind of skill you're going to need to be able to provide, you know, back ports for security fixes, and especially for dependency updates while you're doing your Jakarta EE migration, or while the consumers of your application or framework are making their Jakarta EE migration. So a lot of this is about really more of like a product owner, program management over time, you know, solving those challenges.
And so this, this pre-Jakarta EE release stream really helps with that. So that. So this is where you want to drop any end-of-life and deprecated code modules from your code. You want to upgrade Maven or if you're using Gradle in the plugins there, migrate or drop any end-of-life like third-party dependencies, anything that's redundant that you could use Java built-ins. You know, take the time now to do that, and then it's a good opportunity to upgrade to current non-Jakarta affected dependencies. These are dependencies that are going to get pulled in or dragged in transitively, things like log4j2 JUnit5, things that you've been putting off or your your project managers and product owners haven't been excited about taking the time to, you know, take the time to go do these. So any of these, especially these, break framework libraries that have also revved up, go ahead and grab those, because there's gonna be a good chance that as you upgrade your the your dependencies, they're going to drag these and kind of force you to it anyway. And of course, take this time to update your JDK. What we're doing in height for our products, we're gonna make the jump straight to JDK 21 we're gonna go ahead and skip 17, if you can go from 11 to 21 we think that's a pretty safe and healthy jump if you can do it, but that'd be a good kind of back pocket strategy to take with you.
In the Jakarta EE release stream. This is your opportunity to update to the Jakarta EE APIs. This is where you refactor your code to support the API changes. Some of the most of the fine firm, most of the APIs are a simple name, space changes. A few of them have a couple method signature or new methods that'll change. But, you know, I'd say for the most part, it's, it's pretty standard, and so you might need to refactor your code to support the Jakarta API changes, and possibly on the the implementation of those APIs. May have some code changes for you as well.
Miscellaneous strategies. This is really, I think, just code, project management type stuff, any low impact test only dependencies. You know, if you can say that one of the things we ran into is there was, from a technical debt perspective, ActiveMQ has got about a couple 1000, several 1000 unit tests. And there's, I think, three or four different mock libraries used. And you know, if you've been, you know, consistently coding in Java for the last couple years, you know that mock libraries, test mock libraries change pretty quickly in the flavor of the day, probably a little more rapidly than other ones. So those can be a challenge to deal with, just maintaining those, maintaining the knowledge and the expertise across the different ones, what they do, what their best practices. So you know, this without trying to jump into a big fight. You know, just kind of keep in mind test-only dependencies can be tricky over the over time, because the the cool hotline fades out pretty quick. You know, if you're if you're mocking is simple enough. You know, making a test-only implementation may be the move. If you've got complex in house, things that kind of look more like a framework or a platform, you know, definitely do the two release strategy, get a modernized javax version, and then work on your Jakarta based EE. This is really what we're calling, like the Jetty 12 approach, and then break your commits up. This is a more of like a Git management strategy. This was done in the ActiveMQ, as well. We had a lot of, we broke up the commits and different ways to help manage, you know, keeping the tree, the health of the tree, in good shape. If you can break up your commits to have the Jakarta namespace only changes when you're making that big slice, they review much quicker, because all you're really doing is going through and looking at the import lines. And it might be hundreds or 1000s of those. And so if you make a commit that's simply the import sheet, namespace change, and then the next commit come through, this is going to really speed up your review process, and also the ability for you to back port changes. And if you've got any client side, you know, data only or smallish modules that you can create to kind of separate, again, a lot of this is about dragging transit dependencies. This is similar to what we did in ActiveMQ with that Jakarta module. You know, if you can create some client-side data-only modules, you can kind of decouple yourself from some of the API, as well.
All right, let's take a minute to just look at where ActiveMQ is today. Just kind of give everybody an update First, let's look at the migration stats, though. We'll talk about the release table, and we'll talk a little bit about roadmap, and then we'll be able to roll right into questions. Okay, this is, this ended up being the migration stats. So there was one super big pull request off the main branch. It consisted of 25 different commits over time. That really was about 100 commits during the you know, I think this, this PR, probably sat for months while the the issues were worked through, so it's probably over 100 total commits, but ended up kind of getting merged and shuffled to 25 before the final merge. For a total of 1400, 25 files were changed, little over 9500 lines were added. Another 8000 lines were removed. We dropped two Maven modules from our from the tree. Two dependencies were re-homed. We dropped two frameworks. We had the one J2EE API that we deprecated, that we dropped. There were total like 28 kind of big, chunky work tasks that set on the PR and served as discussion points across the team. And there were about 80 build jobs that ran till we got there. So that's kind of in a nutshell, what it looked like, you know, for ActiveMQ. So if you've got a, you know, decently, a reasonable approximation, in your, your enterprise, in your your bosses and your management team or product owner is asking you, Hey, give us some stats. You could use this as a starting point to provide some estimation of what this would look like.
So this is the release chart today, ActiveMQ, so the 6.0 was the first Jakarta, you know, based broker release, and we've since released a 6.1. So 6.0 was released about a year ago, November 23 currently, the two live release streams are the 6.1 and the 5.18 and you can see here how we're aligning the release versions, JDK, key specs and key, maybe what we're calling, major dependencies. So 6.1 is JDK 17 plus JMS 3.1, Spring 6, Jetty 11. You know, as I mentioned a little bit earlier, we'll be, we are working on making that jump of ActiveMQ to Jetty 12, which will also take us to the latest version of the Kalarta EE so, you know, ActiveMQ, where we jump, where ActiveMQ jumped in was kind of midstream. The whole ecosystem making the change to Jakarta. And so we've got one more step to get current, and then 5.18 is leveled on JDK 11, JMS 2, Spring 5.3, Jetty 9. So then you can see here, 5.18 is where we did that magic, where we supported both. With javax and JMS on the client-side.
Roadmap, exciting, exciting capabilities and features ahead for ActiveMQ, we're adding tons of new metrics for connection, for really just observability, but I call it you know, overall, being able to keep an eye on queue message flows, things like that, especially things that support running inside Kubernetes or cloud environments. You know, we've got organizations really looking to support new multitenancy, Queue-as-a-Service capabilities, and so these metrics really drive to support that. So there's new metrics for connection health, observability. Connection health is important in Kubernetes for when you're running behind load balancers and you're dealing with connections from inside and outside of clusters in the cloud, outside of the cloud, things of that nature. Network connectivity over long distances can be, can be tricky. Also, new metrics for message flow observability, metrics for persistent store performance in the cloud. One of the things we observe is high degree of variance in like persistent store performance. And so if we have more visibility with those metrics, we can identify brokers running on on slow nodes, and just in general, adding more features to enhance currently ActiveMQ has great multitenancy support, but there's always more and more advanced policies that could be added. And so there's new hooks and things being done there to support more capabilities around multitenancy. Also really excited about to be working on this one. So I've got the PR out there. It's pretty close to getting merged for tech Virtual Thread Technical Preview. I know there's already been a couple talks on virtual threads, and ActiveMQ is a great candidate for that. Being able to take advantage of virtual threads and the performance benefits that'll come with that, and then provide even further scalability and performance for ActiveMQ, uh, 7, the plans are starting to come together. 7, all this is really subject to change, but with with Spring really making that announcement that they'll be dropping support for open source releases in the 5 series we're looking in on the ActiveMQ side is dropping Spring as kind of the main bootstrapping wiring component. So we're going to have an option to run Spring-free on the server-side. I'm so excited about that. Still just be a simple, you know, bootstrap component that will replace what Spring does, but along with that, will come with a new configuration service. And the the idea on that is we'd have more ability to do runtime configuration without having to restart brokers, more things about tuning multitenancy, you know, so you can provision multitenancy work, multitenant message flows and things like that, without having to do broker restarts, which is great for when you're doing platforms in the cloud, Queue-as-a-Service, dedicated clusters, Things that, things like that, and then continue to modernize. So really, I think ActiveMQ 7 is about getting back to, you know, getting back to the basics performance, you know, not forcing the Spring pieces in there, and being more, leveraging more the JDK built-ins, like a lot of, what we're suggesting here is go more. You know, JDK native, and that's what ActiveMQ is doing in 7. So the current release stream is v6 one and 6.2 will be the next new feature release stream. So a lot of these new features have already been merged in.
We could take a look at cut down here, kind of a deep dive on the features. It's like the message advanced message statistics. So at enqueue time, you now can see the last enqueued MessageID, what ClientID that was, what? What was the message Timestamp and the BrokerInTime? So you can measure the latency between the application sending and the broker receiving it. Same thing on the dequeue time, you'll get the MessageID, the ClientID, the message Timestamp, what was the BrokerInTime and the BrokerOutTime. So this is in pull request. This will go into 6.2 and 5.18. Similarly, there's an advanced network statistics metric. This is already merged in 6.2, and it's been, already been released in 5.18 But this provides network enqueue and network dequeue counts, so you can get a track when messages come into a queue, was it in enqueued or dequeued via an application connection or a network connection in a cluster, essentially. Virtual thread supports and technical preview. The pull request is already there. It's targeting for 6.2. So 6.2 is really shaping up to be a cool feature release. And you'll see, you'll see a bunch of these features are also going back to that simultaneous 5.18, the message interceptor strategy. This is a per name space capability to provide more multitenant policies. This is really cool, because destination policy is where this is added. This can be used for providing that more advanced multitenant policies, things like on a per message flow basis, what expirations Do you want to allow? Do you want to require compression? Do you want to limit supported message types? Do you want to specify some required headers, things like that? So this is a pretty cool piece on a server-side basis, you can really enforce policy. So if an application were to send something that's outside a policy, it would get rejected at send time. So these kinds of things you could find and hone your application teams in when they're doing their their event-driven applications and messaging applications really adhere to your strategy at a at development time, and instead of waiting to get to production or when you run into a support issue. So the message interceptor strategy piece that's already been released in 5.18 and it's merged into 6.2 So these are some of the exciting things coming in the Jakarta in the pre-Jakarta ActiveMQ releases.
And for reference, on the open source side, we've got a couple links that are tracking the big feature work. So there's a JMS 2 page, which tracks the Jakarta and JMS 3.1/2.0, progress. There's only a couple JMS API spec features that aren't out there or that are not complete. Again, I think we're down to two or three. So those will be wrapped up in the next couple point releases on the 6.0 side, and then also back ported into the 5.18, point releases, and then the virtual thread work that tech right now it's in technical preview. There's a special placeholder page there for that that'll track the progress of that release. Once that goes out, it'll be really interesting to start seeing performance tests comparisons out of the box. The really some of the main locks in ActiveMQ are already reentrant, so it's cool, but there's also a bunch of synchronized spots, so we'll be looking for hot spots in making thoughtful changes on how to optimize ActiveMQ to really take advantage of virtual threads, to be able to, you know, take the benefit of that high connection, high connection count, high destination count, low trap message traffic, I think, is where, where we'll see the big boost when you've got, you know, 1000s and 1000s of connections, or 1000s and 1000s of queues, but you're doing, you know, a really low volume of messages. I think that's where we'll see the virtual threads come in. On this topic, I've blogged about the ActiveMQ transition to Jakarta. I've got two-part, part one and part two. Part one is really an intro about Jakarta. Part Two starts diving in, into the into the guts and the details, like we did in this talk. So check those out. Those are on the HYTE blog, and we'll be posting a part three, which contains most of the content or the remaining content that we've already shared here on this talk. So you'll be able to catch that. And there's a little bit more deep dive in details than there as well.
So Excellent. All right, we're doing okay on time. Let me check and see if we have any questions out there. All right, okay, what is the deal with ActiveMQ Artemis? Is that a different product? Yes, ActiveMQ. So Artemis is a second broker that's under the ActiveMQ umbrella. It was donated to the Apache community. And there was some thought at one point that it might become ActiveMQ 6.x that hasn't been the case. So ActiveMQ 6 is based on, really, that the main broke, Main Line broker that's, you know, pervasively developed. There's just too many changes the, you know, I feel like there's been too many changes. It's been difficult to make that migration from ActiveMQ to Artemis for a lot of folks. So it's gonna be a long run time on ActiveMQ. I'll do another blog post kind of share my thoughts on Artemis in general. So be a lookout for that. But really, what we're seeing is there's a long roadmap and path forward with ActiveMQ 6 and going into ActiveMQ 7. So we're excited about that and where that's going. All right. Well, thank you for the great question, and appreciate you guys joining for my talk.
