On Mon, Oct 5, 2026 at 7:47 AM <[email protected]> wrote: > > 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 > > Thank you, that's a good point, I won't complicate security patches by changing lots of C++ now.
Since Java almost never has security issues, I'll continue pushing Java changes, but I'll make C++ changes in a different branch and only merge or push those once 4.1.x is obsolete.
