Apache OpenOffice (AOO) Bugzilla – Issue 82876
XPackageManager.addPackage(...) does not deal correctly with null in second String
Last modified: 2013-02-24 21:06:47 UTC
I use the XPackageManager.addPackage() method. This method takes 4 arguments. The second is the "media-type of package, empty string if to be detected". If I pass "null" for the second argument, the package is installed without failures. But I cannot use my implemented protocol handler! If I pass just an empty String (""), the package is also installed (again, no failures while installing) and my protocol handler works. Solutions are: 1. Passing "null" should throw an exception and not install the extension 2. Passing "null" should have the same result as passing an empty string I prefer solution 2, although I think this argument is not necessary at all, because of the auto detection of the package type.
jsc -> tobiaskrais: i tend to mark this issue as invalid because a null string is no valid UNO string object in Java-UNO. But i would like to ask SB for his opinion. jsc -> sb: what do you think? The docu says it have to be an empty string.
If the issue is about Java UNO, yes, null is not a valid value here (see <http://wiki.services.openoffice.org/wiki/Uno/Java/Specifications/Type_Mapping#Mapping_Types>). However, IIRC, both the Java URP bridge and the JNI bridge silently treat null Strings the same as empty ones.
any comments from your side Tobias? Otherwise i will mark it invalid and will close it
Yes, a comment from my side: I wasted some the, because I was not reading the documentation very well. Maybe there are others like me... My opinion is as sb wrote: if the null value is treated silently, it should work correct or throw an exception. I think this is a very small fix at the beginning of a method call like (Java): -----%<----- if(param == null) { param = ""; } -----%<----- I think: lets fix it.
jsc -> jl: when you work on the code the next time can you please fix. Although it's formal correct, the fix is simple and we can avoid confusion.
back to me, sorry jl i didn't want confuse you. I talked with SB and he convinced me that it doesn't make sense to fix it in the Package manager. SB pointed out that the bridges silently treat null strings as empty ones. We will check this again.
back to me ...
closed
"SB pointed out that the bridges silently treat null strings as empty ones." For the records: Just had a look at the code. While using null strings as arguments in UNO interface method calls is undefined behavior in Java UNO, various scenarios do behave differently: - The Java URP bridge silently treats null like "" (jurt/com/sun/star/lib/uno/protocols/urp/Marshal.java:1.19 l. 259). The reason is that this was the simplest way to support polymorphic structs. - The JNI bridge throws a com.sun.star.uno.RuntimeException "[jni_uno bridge error] Java calling UNO method createInstance: [map_to_uno():string] null-ref given!" (bridges/source/jni_uno/jni_data.cxx:1.22 l. 407). - Direct Java to Java calls simply pass the null (of course). However, this differing behavior is covered by the specification and is IMO acceptable.