Proposed change in behavior for `@JsProperty`/`@JsType` with non-native Record types about jsinterop-annotations HOT 2 OPEN

Thanks for the write up. I think it generally makes sense though not sure what to do with native types. My quick take is JsType should mean the same thing everywhere and my there is a different annotation if we want to significantly change meaning (like JsFunction, JsEnum etc..).

from jsinterop-annotations.

After some reflection, I think that @JsType(isNative=true) on an enum would be fairly similar in its wrongness, so in the same way that marking a Java enum as a native js type doesn't make sense, I think marking a Java record as native js type probably doesn't make sense.

I think I'd go further at this time and suggest that a closure @record is probably incompatible with Java record, even with a hypothetical @JsRecord annotation to paper over details:

• Java records cannot extend from another record/class - contrast with closure's records, tooling like jsinterop-generator would need to extract extra interfaces to make this work.
• Java records are always immutable (though https://bugs.openjdk.org/browse/JDK-8321133 could make this easier to handle in the future, but not in a js-compatible way) - it would not make sense to say "this java record represents a js record" and then permit the object to change.

Any read I have of it, there is no good analog in closure for an immutable record/struct type - even if you were to find a type already written as

/** @record */
function Book() {};
/** @const {string} */
Book.prototype.title;
/** @const {number} */
Book.prototype.pageCount;
/** @const {string[]} */
Book.prototype.authors;

you still have the "problem"/mismatch that the array in authors is mutable. Maybe we just punt on that, and acknowledge that Java developers will have to be aware that native records won't behave at all like Java records (in contrast to enums which have some compile time limitations, but no cases where values will change in surprising ways).

Given that, is there any way to permit native Java record types, without also applying runtime changes to the objects like calling freeze on them...?

The good news at least is that I don't think this needs to affect non-native records:

• Either (non-native) @JsType'd Java records must follow the constraints above (so that they can compile at all in j2cl/gwt, without field/method naming issues), or
• Java records must never be annotated with @JsType or compile errors will arise (without mandating that every record component get an extra annotation), and possibly
• Java records must never be annotated with @JsType, but a never-native annotation such as @JsRecord be introduced to specifically handle this case and allow @JsType to never make exceptions for the above.

from jsinterop-annotations.