Rather than forking I think it would potentially make more sense for you to become a committer here at Apache. Then updates could take place in stages. I think the first step would just involve getting things working on C++17. Larger changes would come later. Changes to the public API would require a new major version.
I wasn't part of the community when the activemq-cpp client was first released back in 2007 (18 years ago now), but my general understanding is that folks wanted to enable ActiveMQ messaging from the most popular languages of the day - Java, .NET, & C++. Java, of course, had JMS already so they created NMS and CMS - corresponding APIs for .NET and C++ respectively. Right or wrong, these APIs mirrored JMS which made development and documentation more straightforward than creating something from scratch. That was, of course, a trade-off. All these APIs were implemented with code speaking the OpenWire protocol (i.e. the "native" protocol of ActiveMQ Classic). However, in the nearly 2 decades since then new ISO standard protocols have gained wide adoption across the industry, namely AMQP & MQTT. Of course, we can't forget STOMP which, while it is not an ISO standard, is a de facto industry standard. These protocols have client implementations across a wide variety of languages and platforms, and there are lots of brokers which support these as well. Open standards are good for the industry and specifically good for users since it provides greater freedom when choosing vendors. Given this, it's not clear to me that continued investment in CMS (and the C++ implementation) makes sense. Clearly the folks that originally championed this stuff have moved on to other things. I'm curious if you've tried (or considered trying) the Qpid Proton C++ client [1]. The activemq-cpp code-base [2] only has 4 contributors whereas Qpid Proton [3] has over 50. Justin [1] https://qpid.apache.org/releases/qpid-proton-0.40.0/proton/cpp/api/tutorial_page.html [2] https://github.com/apache/activemq-cpp [3] https://github.com/apache/qpid-proton On Wed, Feb 12, 2025 at 4:48 PM Arjun Ray <ara...@gmail.com> wrote: > On Wed, 12 Feb 2025 11:39:19 -0700, Arthur Naseef > <artnas...@apache.org> wrote: > > | It would be great to have some attention on this project, if folks > | are still using it in practice. > > I'm sure there are more than a few, but the number is likely to > dwindle for lack of support. > > | With that said, as with all opensource, there is no dedicated person > | assigned to activemq-cpp. It really comes down to having folks > | willing to contribute [...] > > Yes, but where and how? There is a JIRA list, associated with a > Github repo (a fairly normal setup), but the gatekeepers seem retired. > IOW, it's _pointless_ to open a JIRA, make a patch, and submit a pull > request, as it will simply be ignored. > > Or worse. Someone actually proposed a proper fix two years before I > joined this list (as I linked to, earlier), and this is what happened: > > https://issues.apache.org/jira/browse/AMQCPP-628 > > The conclusion is that nothing rates to be done without forking. The > old setup is dead, with gatekeepers intent on keeping it that way. > > | As far as the java-isms in the code, I understand your feeling. The > | original code was a pretty straight-forward translation of the java > | code into C++. > > I suspected as much, but this is the first positive confirmation I've > seen. Thanks! > > | One advantage of this approach was that it made comparing the state > | of the two projects straight-forward. > > I have some sympathy for this idea, but not much. There are vast > differences between Java and C++ that surface similarities in syntax > tend to obscure. In general, C++ emulation of Java code is a very bad > idea.[*] (The better approach would be for both sub-projects to follow > a detailed spec, but that raises the spectre of good documentation, > the impatient programmer's favorite nightmare:-)) > > | With that said, having code that follows modern best-practices and > | standards is welcome. > | > | Are you interested in contributing? > > TBH, I'm of two minds on this. I would very much _like_ to contribute, > mainly because I think ActivemQ (Classic) and the C++ client are well > tested software and thus valuable. But I have serious reservations. > > First, as alluded to above, I don't see anything at all happening > without a fork - in effect, starting afresh, albeit with an intact > code base. I don't know what institutional and/or infrastructural > roadblocks would need to be hurdled for that. > > Second, modernizing the codebase is a _huge_ ask. And I don't think > "just get it to compile under C++17" is necessarily the best place to > start. Things like the APR library and decaf need to be replaced - > they are thoroughly obsolete blobs of code. Moreover, certain > prominent Javaisms need to go. E.g., emulations of Java's anemic > iterators and its 'synchronized' keyword, and the endemic use of heap > allocated locals. These are all utterly gross. > > Third, the inheritance hierarchies are ridiculously deep. That may be > the "Java way of doing things" (I have my doubts on that score as > well), but it is certainly not the C++ way. A lot of intermediate > "interface" classes strike me as useless baggage and clutter. (While > on that subject, Java's 'import' keyword seems to have inspired a > ridiculous profusion of '#include' directives. Whatever happened to > forward declarations too?) > > Fourth, the public facing interfaces (as well as some internal ones) > also need a re-think. Not leveraging covariant return types is an > obvious deficiency. Worse is enforcing heap allocation with external > release (i.e. explicit creational methods only). > > I guess we need a thorough spec for the things that need to be fixed > to get the ball rolling. > > Arjun > > [*] For a classic example of the pitfalls, see > > https://stackoverflow.com/questions/31383751/log4cxx-segmentation-fault-in-apr-pool-create-ex/58805010#58805010 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > For additional commands, e-mail: dev-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > >
