Hi Since we now require Java 8 (00a90ea2c35aa0d62b41963f97bc10041530f5d1) and C++ 2011 (91144cd0085a7583d2099b982122deb2184ab956), it would be good to update our source code accordingly.
-------- 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. Regards Damjan
