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
