Am 05.10.2026 um 06:56 schrieb Damjan Jovanovic:
Hi Since we now require Java 8 (00a90ea2c35aa0d62b41963f97bc10041530f5d1) and C++ 2011 (91144cd0085a7583d2099b982122deb2184ab956), it would be good to update our source code accordingly.
+1
-------- Java -------- The very old Java code we have uses java.util.Vector (from Java 1.0) a lot, which is problematic as all its methods are synchronized, while the more modern java.util.ArrayList (Java 1.2) doesn't lock which is faster. The same is true with at least java.lang.StringBuffer (1.0) vs java.lang.StringBuilder (1.5), and java.util.Hashtable (1.0) vs java.util.HashMap (1.2). Furthermore a lot of code is written for Java <= 1.4, which had no generics, and was forced to use a lot of casts. Even for some common calls to our own APIs, which were made generic, the calling code was never updated to drop the unnecessary casts. I've begun improving some of this, with positive results. UnoRuntime.queryInterface() is very heavily used, and the cast on its return value is almost never necessary. With a little script I wrote to look for "UnoRuntime.queryInterface" and analyze surrounding code and delete casts where possible, I've deleted 7366 unnecessary casts, which has reduced the total size of all our source files by 124 kB. And many more casts could be removed, such as from AnyConverter.toObject(). All use of java.lang.StringBuffer has been replaced by java.lang.StringBuilder. Regarding java.util.Vector and java.util.Hashtable, I am less certain. It appears that, at least in certain cases, code may have been written to rely on their synchronized behaviour. For example in main/javaunohelper/com/sun/star/comp/helper/ComponentContext.java there is no synchronization being done on the m_eventListener Vector, despite the fact it could be accessed from multiple threads, presumably relying on the Vector's internal synchronization... Converting this to java.util.ArrayList would result in race conditions. So far I've only converted java.util.Vector to java.util.ArrayList in cases where it is safe, where the Vector is created temporarily and not visible to other callers, such as within a method. My changes have been pushed to trunk, please let me know if you find any problems. ------- C++ ------- Since we started with C++ 2011, the build output has never looked uglier, with tons of warnings everywhere. Some of these would be a good idea to fix, for example the deprecated ::std::auto_ptr could be replaced by ::std::unique_ptr in many places, which would also make ownership clearer and safer from serious memory bugs. Some people recommend a global search and replace of auto_ptr with unique_ptr ( https://stackoverflow.com/questions/3451099/stdauto-ptr-to-stdunique-ptr). In my quick test on main/codemaker and main/idlc, the search and replace to unique_ptr does work, the modules compile successfully, but these are small standalone tools that only use these smart pointers internally within methods. How the change behaves more broadly, remains to be seen.
I think this is to early. It makes back ports of fixes more work. unlike Java 4.1.x is the blocking factor if we want to cause more work for security patches.
I would suggest we target a V5 release end of the year and start the code overhaul after we have abandoned 4.1.X. I have a 4.2 branch boost-imprint-reduction, that started to prepare this move. It makes the change using standard features, but adds a fallback
method to old boost in case old compilers are used. However since we moved to v5, this mechanism became obsolete. And i need to adjust the branch. But I did not do this because of the blocker i mentioned before. I see this effort after we released v5 and abandoned 4.1.X
Another method could be that we move to bazel. which can build V5 with modern compiler, and knows how to downgrade to build on winXP with old stack.
But honestly i dont think it is worth the effort. my 2 cents
Regards Damjan
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
