[JAVA_API] Fix ElementType compatibility problem introduced in 2025.1

[ClaudioPaul0]

Breaking change was introduced here

ElementType.undefined was deprecated and its value was changed to be equal to ElementType.dynamic which caused a shift of the value of the remaining types.

Also undo changes done to modules/java_api/src/test/java/org/intel/openvino/CompiledModelTests.java and modules/java_api/src/test/java/org/intel/openvino/ModelTests.java which changed expected types from ElementType.f32 to ElementType.f16 in this commit which is incorrect since the actual type of the input and output of the model is f32

[ilya-lavrenov]

build_jenkins

[praasz]

Why new type added as PR only fix compatibility issues after deprecation of undefined?

[ClaudioPaul0]

The added type has nothing to do with the fix of the problem. The problem comes from the usage of two Type_t entries using the same int value 0 (undefined and dynamic).

The fix was subtracting 1 from the values of ElementType.java

Take a look at the following example:

#include <iostream>


enum class OldType_t {
    undefined,  // 0
    dynamic,    // 1
    boolean,    // 2
    bf16,       // 3
    f16,        // 4
    f32,        // 5
    f64,        // 6
    // etc...
};

constexpr size_t idx(OldType_t e) noexcept {
    return static_cast<std::underlying_type_t<OldType_t>>(e);
}


enum class NewType_t {
    dynamic,              // 0   
    undefined = dynamic,  // 0
    boolean,              // 1  <-- value changed
    bf16,                 // 2  <-- value changed
    f16,                  // 3  <-- value changed
    f32,                  // 4  <-- value changed
    f64,                  // 5  <-- value changed
    // etc...
};

constexpr size_t idx(NewType_t e) noexcept {
    return static_cast<std::underlying_type_t<NewType_t>>(e);
}


int main()
{
    std::cout << "Old values:"
            <<" undefined="<< idx(OldType_t::undefined)
            <<" dynamic="  << idx(OldType_t::dynamic)
            <<" boolean="  << idx(OldType_t::boolean)
            <<" bf16="     << idx(OldType_t::bf16)
            <<" f16="      << idx(OldType_t::f16)
            <<" f32="      << idx(OldType_t::f32)
            <<" f64="      << idx(OldType_t::f64) << std::endl;


    std::cout << "New values:"
            <<" undefined="<< idx(NewType_t::undefined)
            <<" dynamic="  << idx(NewType_t::dynamic)
            <<" boolean="  << idx(NewType_t::boolean)
            <<" bf16="     << idx(NewType_t::bf16)
            <<" f16="      << idx(NewType_t::f16)
            <<" f32="      << idx(NewType_t::f32)
            <<" f64="      << idx(NewType_t::f64) << std::endl;

    return 0;
}

Old values: undefined=0 dynamic=1 boolean=2 bf16=3 f16=4 f32=5 f64=6
New values: undefined=0 dynamic=0 boolean=1 bf16=2 f16=3 f32=4 f64=5

[praasz]

The added type has nothing to do with the fix of the problem, this was reason for question why is added if not related to the issue.

Fix for values of ElementType.java is OK.