Between V 4.4.7 and V 5.0.2 the ImplementationName com.sun.star.comp.math.FormulaDocument was changed to com.sun.star.comp.Math.FormulaDocument This broke backward and forward compatibility in some cases and created a new conflict with AOO and most likely with some extensions. ImplementationName and SupportedServiceName are generally tested case sensitive. (Was there an urgent reason for the change? Was it published? I couldn't find it in the release notes.) Simply check. No demo or advice how to reproduce needed.)
Perhaps this was https://cgit.freedesktop.org/libreoffice/core/commit/?id=3099c70b11c7e5b80fe4dbe3dc99171fb38c6fc2 OUString SmModel::getImplementationName(void) throw( uno::RuntimeException, std::exception ) { - return OUString("com.sun.star.comp.math.FormulaDocument"); + return OUString("com.sun.star.comp.Math.FormulaDocument"); } where there seems to have been an inconsistency before that where Math.FormulaDocument is used in some places and math.FormulaDocument in that one place
Background information: We only have 6 files with "com.sun.star.comp.Math.FormulaDocument" string [1]. Except 1 of them (unomodel.cxx), all others had current case ("Math") from the beginning ([2], [3], [4], [5], [6]). The last one included the string with lower-case "math" with commit [7]. In commit [8] this was changed. I didn't try to reproduce the incompatibility issue, so no state change. [1] https://opengrok.libreoffice.org/search?project=core&q=%22com.sun.star.comp.Math.FormulaDocument%22 [2] https://opengrok.libreoffice.org/xref/core/embedserv/source/embed/guid.cxx?r=a934115b [3] https://opengrok.libreoffice.org/xref/core/starmath/source/unodoc.cxx?r=f807e70e [4] https://opengrok.libreoffice.org/xref/core/starmath/util/sm.component?r=01c2f02e [5] https://opengrok.libreoffice.org/xref/core/odk/examples/java/EmbedDocument/Container1/EmbedContApp.java?r=ab9f3ab8 [6] https://opengrok.libreoffice.org/xref/core/embeddedobj/test/Container1/EmbedContApp.java?r=68d5a4ca [7] https://cgit.freedesktop.org/libreoffice/core/commit/?id=495f53c8 [8] https://cgit.freedesktop.org/libreoffice/core/commit/?id=3099c70b
Thanks for th quick response. The only place for me to see the ImplementationName of FormuladDcuments was the value shown in the BASIC IDE for an example object inspected there. I tried to help two requesters in ask.libreoffice.org and in forum.OpenOffice.org who had similar questions within a day. Based on a piece of older code and the above mentioned look into the IDE I wrote the short sub in LibO 5.4 and published it in the OO forum where LibO users alao are welcome. The one who had asked, however, had informed he used AOO, and therefore I also tested the code under AOO. FAIL! The analysis showed that in AOO up to date and in LibO as well till V 4.4.7 the ImplemenationName acctually accessible as the object's property had the lower case ".math." The change to ".Math." without notice was with V 5.0 (I tested with 5.0.2). I might not be the only one who worries (if at all) about the actually acessible strings, not about those which may occur elsewhere in the dark where probably no case sensitive comparisons are made. Is there a mandatory naming scheme that required the change despite the fact that it should be expected to cause incompatibilities? See https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=89962#p424628 . (Expand the code view to find the critical lines.)
According to the DevGuide [1] implementation names are *not* supposed to be compatible. If this is true, it shouldn't be an issue (as long as there are good reasons to change these names internally). However if for some case there is a known 3rd-party code which use the impl. name, it might be better idea to stick to the old name anyway (like in Bug 92668). But I don't know if that's the case here. [1] https://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/XServiceInfo
I suppose that it's too late to revert, unfortunately. The change lives in released code for 2 years already, and must have generated its own plethora of incompatible macros in our install base. Also, the patch changed a number of other names as well.
Macros checking for the specific ImplementationName of a com.sun.star.comp.FormulaDocument object may not be widespread at all. For me (using Division's Star- Sun's Star- org's Open- Apache's Open- and Libre- Office for decades now) it was the first time I accessed it. And for the two years the change is "living" now no bug report about it was filed seemingly. I did. Not because I insist on action, but because I want the devs to know. Ok. I can work around. But there may even be more OO.o and AOO users who actally did some document automation than LibO users did. They will be angry with LibO once more if they try and fail. AND The .supportsService() method (which I mostly prefer for case checks) also is case sensitive. A workaround here, one there... I would like to hear that developers will be aware of the fact that any tiny change in the field can afflict code. If a piece of code like mine ceases working, well... (see above), but if a valuable and widespread extension fails... Many developers of older well proven extensions, I'm afraid, no longer maintain their free products... Weapons for those not exactly benevolent concerning free software. Do you follow the Limux case? Free software will never be fully compatible. The commercial competitors have the power to make this impossible. Free siftware must be better. Long-term stability is essential.
This is a bit complicated: 1 Requesting the SmModel UNO object implementation (e.g. via ServiceManager's css.lang.XMultiServiceFactory::createInstance) has always been done with uppercase "com.sun.star.comp.Math.FormulaDocument", as spelled out in SmDocument_getImplementationName (starmath/source/unodoc.cxx) ever since <https://cgit.freedesktop.org/libreoffice/core/commit/?id=f807e70ecddb785474289e2553968ec376b28d6f> "INTEGRATION: CWS mav3 (1.1.2); FILE ADDED". (First by the code in component_writeInfo/getFactory calling SmDocument_getImplementationName since <https://cgit.freedesktop.org/libreoffice/core/commit/?id=726125348e86b557e27ea09148f2e7afe5361bbb> "INTEGRATION: CWS mav3 (1.4.38); FILE MERGED". Then by replacing component_writeInfo (but keeping component_getFactory calling SmDocument_getImplementationName) with starmath/util/sm.component in <https://cgit.freedesktop.org/libreoffice/core/commit/?id=01c2f02ec849927b69d9ec7b9c1c147ad56b599f> "sb129: #i113189# change UNO components to use passive registration". 2 Asking the SmModel UNO object implementation for its implementation name (via css.lang.XServiceInfo::getImplementationName, i.e., definition of SmModel::getImplementationName in starmath/source/unomodel.cxx) had returned various values over time, most of them not matching the value from (1) above: ** "SmModel" since <https://cgit.freedesktop.org/libreoffice/core/commit/?id=d791366863cf9659a01b171ce0e727bfe2f28cdf> "initial import" in 2000. ** "com.sun.star.comp.math.FormulaDocument" since <https://cgit.freedesktop.org/libreoffice/core/commit/?id=495f53c8b40170a05ff95e8573131fba599c6cab> "INTEGRATION: CWS fwkq1 (1.24.26); FILE MERGED" in 2003. ** "com.sun.star.comp.Math.FormulaDocument" since <https://cgit.freedesktop.org/libreoffice/core/commit/?id=3099c70b11c7e5b80fe4dbe3dc99171fb38c6fc2> "Fix various XServiceInfo implementations" in 2015, to get the values of (1) and (2) in sync for postprocess/CppunitTest_services.mk (which checks that such values are actually in sync). Now, to turn (2) back to lowercase "com.sun.star.comp.math.FormulaDocument", there would be two options: Either also change the value for (1) to lowercase "com.sun.star.comp.math.FormulaDocument". That appears to be a rather dangerous change, potentially leading to broken 3rd party code; in the LO code itself, there are various places that would need to be adapted (and cause "make check" to fail if not adapted). Or else make (1) and (2) inconsistent again. That would mean that postprocess/CppunitTest_services.mk needs to be dumbed down, and would re-introduce a (potentially confusing) inconsistency. Neither of these two options looks appealing. 3rd-party code should not rely on the implementation names of UNO objects. Some such code certainly does, for various reasons. In comment 3 Wolfgang Jäger states that two questioners in forums had issues with this, but leaves it unclear how severe those issues were (i.e., whether it actually broke existing code). In comment 0 and comment 6 he remains vague ("most likely", "no bug report about it was filed seemingly") on whether the current state has known bad consequences. Thus, unless evidence of known bad consequences is brought forward, I would like to close this issue as WONTFIX. (And will do so if there's no new input coming.)
(In reply to Stephan Bergmann from comment #7) > This is a bit complicated: > ... > ... > > 3rd-party code should not rely on the implementation names of UNO objects. > Some such code certainly does, for various reasons. In comment 3 Wolfgang > Jäger states that two questioners in forums had issues with this, but leaves > it unclear how severe those issues were (i.e., whether it actually broke > existing code). I was very clear about this in comment 3 and elsewhere. (Too many words, probably.) I stated it was myself who experienced the issue when trying to help the questioners. I stated I knew a workaround. > ... In comment 0 and comment 6 he remains vague ("most likely", > "no bug report about it was filed seemingly") on whether the current state > has known bad consequences. I thought I was clear about NOT knowing FORMERLY occurring consequences. The issue I mentioned above I solved by testing for the service "com.sun.star.formula.FormulaProperties" using 'supportsService' instead of for an ImplementationName by explicit string comparison. (Testing for services I prefer anyway generally.) But: If the names of services and interfaces also are "subject to change" under something like the above quoted statement by Stephan Bergmann, how should someone write long-term-reliable code ("3rd-party") for special requirements or for a distributable extension? How should a decider be sure an investment in document automation based on LibreOffice for a large organisation would pay instead of just creating problems? Where old naming differences in source files occur, a main concern should be that the one(?) naming is persistent which is returned if a respective object is asked by code running for a document. > Thus, unless evidence of known bad consequences is brought forward, I would > like to close this issue as WONTFIX. (And will do so if there's no new > input coming.) I would still insist that my comments were rather clear. As I am not an insider the terminology may have flaws. Once again from my comment 6 : I would like to hear that developers will be aware of the fact that any tiny change in the field can afflict code. If a piece of code like mine ceases working, well... (no big problem), but if a valuable and widespread extension fails... It should also be clear that the failing I observed concerned compatibility with AOO and backward/forward compatibility between LibO versions. No objections against WONTFIX. Objections against future changes in names (if avoidable at all).
(In reply to Wolfgang Jäger from comment #8) > But: If the names of services and interfaces also are "subject to change" > under something like the above quoted statement by Stephan Bergmann, how > should someone write long-term-reliable code ("3rd-party") for special > requirements or for a distributable extension? Just to clarify: Names of services and interfaces are not "subject to change", only implementation names are. That is, checking with supportsService is the right thing to do, and is what was guaranteed to stay compatible across versions.
(In reply to Maxim Monastirsky from comment #9) > (In reply to Wolfgang Jäger from comment #8) > > But: If the names of services and interfaces also are "subject to change" > > under something like the above quoted statement by Stephan Bergmann, how > > should someone write long-term-reliable code ("3rd-party") for special > > requirements or for a distributable extension? > Just to clarify: Names of services and interfaces are not "subject to > change", only implementation names are. ... Thank you very much. This clarifies the situation for me. I didn't know a specification to that effect. However, what I need to know are the services. And in by far the most cases I tested for service support. Then there was an exception... > ... That is, checking with > supportsService is the right thing to do, and is what was guaranteed to stay > compatible across versions. Would you mind to tell me where the "guarantee" is given?