Extending enums in IDL

Hi Eike,

Eike Rathke píše v Út 22. 11. 2016 v 21:43 +0100:

> For Java, receiving an unknown UNO API enum value results in a null
> value. That can happen if an external Java process not knowing about the
> new enum value using older LO jar files connects against a LibreOffice
> process.

I heard this argument several times before, but did not actually care
enough to dig deeper into it; I just assumed that Java has some kind of
'enum' type that we use in the java bindings, and Things Break Horribly
(TM).

But you caught my interest now - so if I understand that correctly, it
is not a terrible breakage what's going on here: The client just gets an
unknown value; ie. the same thing as when we add a constant to the IDL,
and return this unknown new value - right?

I had a look what we actually do with the 'enum'; it's the following:

> javap workdir/CustomTarget/unoil/javamaker/com/sun/star/sheet/GeneralFunction.class
public final class com.sun.star.sheet.GeneralFunction extends
com.sun.star.uno.Enum {
  public static final com.sun.star.sheet.GeneralFunction NONE;
  public static final int NONE_value;
  public static final com.sun.star.sheet.GeneralFunction AUTO;
  public static final int AUTO_value;
[...]
  public static com.sun.star.sheet.GeneralFunction getDefault();
  public static com.sun.star.sheet.GeneralFunction fromInt(int);
}

So it is subclassed from

  ridljar/com/sun/star/uno/Enum.java

which does not even indicate we'd get a null, but only the (unknown)
value.

For comparison, the constants look like this:

> javap workdir/CustomTarget/unoil/javamaker/com/sun/star/sheet/ConditionEntryType.class 
public interface com.sun.star.sheet.ConditionEntryType {
  public static final int COLORSCALE;
  public static final int CONDITION;
  public static final int DATABAR;
  public static final int DATE;
  public static final int ICONSET;
}

From all this, it seems to me that adding a new value to the enum is no
different than adding a new constant: in both cases the client just gets
a value it does not understand, and has to deal with that.

Of course - adding the value in the middle of the enum is a different
story, as the rest of it gets renumbered (which _is_ a real problem, and
should be avoided), but adding at the end seems to me like something we
shouldn't be afraid of - it's just the same as adding a new constant.

Or am I missing anything?

Thank you,
Kendy