https://openjdk.java.net/jeps/395 added Records to Java 16 as a finalized feature. In the course of implementing this for GWT 2, we've observed that it might make sense to slightly modify @JsProperty for non-native types in a way that doesn't automatically produce errors. It could also make sense to change how @JsType behaves on non-native records to automatically expose record components as properties rather than methods.
From the JEP:
A record class, and the components in its header, may be decorated with annotations. Any annotations on the record components are propagated to the automatically derived fields, methods, and constructor parameters, according to the set of applicable targets for the annotation. Type annotations on the types of record components are also propagated to the corresponding type uses in the automatically derived members.
This means that if @JsProperty is annotated on a record component, it will propagate to both the accessor method and the private final field. That is,
record Point(@JsProperty int x, @JsProperty int y) {}would effectively become
record Point(@JsProperty int x, @JsProperty int y) {
@JsProperty
private final int x;
@JsProperty
private final int y;
@JsProperty
public int x() {
return this.x;
}
@JsProperty
public int y() {
return this.y;
}
}This seems problematic for two reasons:
- First, while jsinterop annotations are allowed on private members, they are not allowed on two members with the same name - x and x() would collide.
- Second, x() and y() do not follow the expected name pattern.
Possible workarounds:
- Changing the record component annotation from
@JsProperty int x to @JsProperty("x") int x would technically resolve the naming issue, but with unnecessary verbosity, and still not correct the first problem
- Even more verbosity could let a developer skip the annotation on the record component and instead add it to the accessor directly, writing:
record Point(int x, int y) {
@JsProperty
public int x() {
return this.x;
}
@JsProperty
public int y() {
return this.y;
}
}This is usable, but arguably what the user clearly meant to begin with.
I propose instead that
@JsProperty on record component accessors not require that the accessor be named as a Bean getter, but reflecting the immutable nature of the record, only be named for the component.@JsProperty on record instance fields are ignored if they are also present on the matching accessor method. This would allow a collision in naming, where the accessor should always "win" when exposing to JS.
Next, decorating a record with @JsType. This is unlikely to reflect the developer's intent, as by default the constructor and accessor methods would be treated as if decorated with their default jsinterop annotation. Instead, I suggest that the methods should be exported as properties. This makes the above example even simpler, offering a simple immutable record/struct to JS:
@JsType
public record Point(int x, int y) {}As the constructor and accessors are implicit (but can be explicit, and in the case of the constructor, compact), if declared they could have their own jsinterop annotations present (@JsIgnore, for example), and if other methods are added, they would follow the standard rules that JsType follows - if public, they are annotated as expected. As records cannot have non-static fields added explicitly, this effectively means only constructors and methods will be able to be exposed in this way.
One observation: the compact constructor, in conjunction with these rules could simplify records with many components. Instead of the initial example where each component was annotated with @JsProperty, we could instead see
@JsType
public record Book(String title, int pageCount, List<String> authors) {
@JsIgnore
Book {
}
}
It may also make sense to offer new behavior for native records, so a native Java record means something - perhaps a closure struct could make sense here? This would mean that invoking a native Java record's constructor would serve to create an object with the expected components, simple syntactic sugar to replace the interfaces with create() factory method that jsinterop-generator currently produces. This is a little more opinionated though (dealing with immutability, etc), so could be taken up separately.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent