Defined subtype is not available in generated Java API

[MisterGC]

Consider the following schema:

package myschema;               
                            
struct MyTemplate<MY_TYPE>      
{                                
    MY_TYPE value;              
};                              
                                 
subtype MyTemplate<int32> MyType;

When generating the API for Java, there is no class/type-identifier MyType available, for Python and C++ there is.
I expected that subtype defines something that has to be provided by the API regardless of the target language.

[mikir]

Java language does not support some alternative to C++ typedef. Therefore subtypes in Java is resolved during API generation (resolved means that generated Java API uses always original type directly).

We might consider to use duplication or inheritance in the previous example but we will still have a problem for native types:

subtype uint32 U32;

Besides of that, subtype in Zserio means alias which allows writing the following schema:

struct Identifier
{
    uint32 id;
};

subtype Identifier Parameter;

struct Consumer(Parameter parameter)
{
    uint32 value;

    function bool isIdZero()
    {
        return parameter.id == 0;
    }
};

struct Holder
{
    Identifier identifier;
    Consumer(identifier) consumer1;
    
    Parameter parameter;
    Consumer(parameter) consumer2;
};

So, because Zserio language uses alias, we must find out the real alternative in Java to be able to generate working code.

[westphal-michael]

In Java I would expect something like this for the code above:

private interface Id {
    public long getId();
}

private class Identifier implements Id {
    long id;
    
    public long getId() {
        return id;
    }
}

private class Parameter extends Identifier {
}

private class Consumer {
    private long value;
    
    public Consumer(Id parameter) {
        value = (parameter != null) ? parameter.getId() : 0;
    }
    
    public long getValue() {
        return value;
    }
}

private class Holder {
    private Identifier identifier;
    private Consumer consumer1;
    private Parameter parameter;
    private Consumer consumer2;
    
    Holder(Identifier identifier, Parameter parameter) {
        consumer1 = new Consumer(identifier);
        consumer2 = new Consumer(parameter);
    }
}

[mikir]

Additionally, Consumer must store parameter and implement the corresponding getter:

private class Consumer {
    private Id parameter;
    private long value;
    
    public Consumer(Id parameter) {
        this.parameter = parameter;
        value = (parameter != null) ? parameter.getId() : 0;
    }
    
    public Id getParameter()
    {
        return parameter;
    }

    public long getValue() {
        return value;
    }
}

There is one limitation and this is that getter getParameter() cannot return Parameter instance but interface only (#438 (comment)). This is not very intutive but it could be acceptable.

[westphal-michael]

Using the interface would be fine from my side, this is my preferred approach anyway.

[mikir]

Regarding problem with native/primitive types, we might think to use objects instead of them. In this case, we will be hit by significant memory and performance penalty. The fresh comparison of memory and performance between primitives and objects is available at https://www.baeldung.com/java-primitives-vs-objects.

[westphal-michael]

I'm not sure which approach is better. From raw performance (and memory consumption) aspect the native types are much better. But as soon as values are copied the object approach could be better so that the performance difference could be smaller at the end, see e.g. https://www.geeksforgeeks.org/primitive-data-type-vs-object-data-type-in-java-with-examples/

[mikir]

Except of performance, the problem would be as well clumsy interface. This is because operators are not possible to overload, so we would need to implement something like setValue() or getValue() which probably users never accept for primitive types.

[mikir]

The solution for classes (not for native/primitive types) could be if subtypes will be modeled by inheritance of original types and original types will be used everywhere instead of subtypes. Or maybe even better original types will define interface which will be implemented by all subtypes.

[westphal-michael]

See my above code, I would vote for an interface for the original type (example interface Id) and then classes implementing it (examples Identifier and Parameter) - which could use inheritance themselves if it makes sense (example Parameter).

[mikir]

Thanks a lot for contribution. Something like this we had in mind with "original types will define interface which will be implemented by all subtypes".

[Mi-La]

Note that even with interfaces the getters will still return only the interface, so that the following Java code will not compile:

someZserioObject.setMyField(new MySubtype(10)); // here it works since MySubtype will down-cast to MyBaseType
final MySubtype field = someZserioObject.getMyField(); // myField member will always be of type MyBaseType and thus the up-cast will not work automatically

The member cannot by of type MySubtype since it then wouldn't be possible to call setter with MyBaseType.

[mikir]

We have created a corresponded design note to put together what we have learned in this issue.

[mikir]

Please see issue #578 as well.