Incorrect conversion in JNI for non-nullable built-in Blob type

[Blastbit513]

The built-in Blob type represents std::shared_ptr< std::vector<uint8_t> > in Cpp and byte array in Java.
So Blob can't be nullable in java and must translate to empty array unless it marked @ Nullable (Blob?) type which is std::optional< std::shared_ptr< std::vector<uint8_t> > > in Cpp.

JNI converter converts an empty shared_ptr to null that looks wrong and leads to a runtime exception.
gluecodium/src/main/resources/templates/jni/utils/JniCppConversionUtilsImplementation.mustache

JniReference<jbyteArray>
convert_to_jni( JNIEnv* env, const std::shared_ptr< std::vector< uint8_t > >& nvalue )
{
    if ( !nvalue )
    {
        return {};
    }

    jsize size = static_cast< jsize >( nvalue->size( ) );
    auto jresult = make_local_ref(env, env->NewByteArray( size ));
    const jbyte* jbuffer = reinterpret_cast< const jbyte* >( nvalue->data( ) );
    env->SetByteArrayRegion( jresult.get(), 0, size, jbuffer );

    return jresult;
}

I would suggest converting an empty pointer to an empty java bytearray like in the patch below

diff --git a/gluecodium/src/main/resources/templates/jni/utils/JniCppConversionUtilsImplementation.mustache b/gluecodium/src/main/resources/templates/jni/utils/JniCppConversionUtilsImplementation.mustache
index a6fedb659..f33eb19d8 100644
--- a/gluecodium/src/main/resources/templates/jni/utils/JniCppConversionUtilsImplementation.mustache
+++ b/gluecodium/src/main/resources/templates/jni/utils/JniCppConversionUtilsImplementation.mustache
@@ -194,7 +194,7 @@ convert_to_jni( JNIEnv* env, const std::shared_ptr< std::vector< uint8_t > >& nv
 {
     if ( !nvalue )
     {
-        return {};
+        return make_local_ref(env, env->NewByteArray( 0 ));
     }

     jsize size = static_cast< jsize >( nvalue->size( ) );

[DanielKamkha]

Nullable Blobs also need to be tested for Swift and Dart generators, in case some similar bug is also present there.

[DanielKamkha]

Having a null shared pointer coming from C++ when the type is specified as non-nullable in the IDL is a violation of contract. This specific issue with Blobs only happens because there is no compiler-level mechanism to enforce this contract in C++. The contract is expresses with a @NotNull documentation comment in the generated C++ code. But then the C++ implementer is free to ignore it.

The real question is how to handle such contract violations in the conversion code. Current "approach" in JNI is to silently ignore it. If we continue to use this approach, then the proposed fix for the Blobs issue is correct. But do we? What if we throw instead (for Blobs and for classes/interfaces)? @Hsilgos, any preferences?

[DanielKamkha]

The whole Blob type looks to be controversial, on all levels (C++, JNI, Java). There's also no consensus on how to improve it. Therefore, implementing the proposed fix as a non-breaking stop-gap measure for now.

[DanielKamkha]

Created #934 for future Blob improvements.