Kotlin mutators

Question

I'm using Ektorp as CouchDB "ORM" but this question seems to be more general than that. Could someone explain what is the difference between

@JsonInclude(NON_NULL)
abstract class AbstractEntity(
        id: String?,
        revision: String?
) {

    @JsonProperty("_id")
    val id: String? = id

    @JsonProperty("_rev")
    val revision: String? = revision

}

and

@JsonInclude(NON_NULL)
abstract class AbstractEntity(
        @JsonProperty("_id")
        val id: String? = null,
        @JsonProperty("_rev")
        val revision: String? = null
)

?

For the first case Ektorp does not complain but for the second it says:

org.ektorp.InvalidDocumentException: Cannot resolve revision mutator in class com.scherule.calendaring.domain.Meeting

    at org.ektorp.util.Documents$MethodAccessor.assertMethodFound(Documents.java:165)
    at org.ektorp.util.Documents$MethodAccessor.<init>(Documents.java:144)
    at org.ektorp.util.Documents.getAccessor(Documents.java:113)
    at org.ektorp.util.Documents.getRevision(Documents.java:77)
    at org.ektorp.util.Documents.isNew(Documents.java:85)

In addition to that if I do

@JsonInclude(NON_NULL)
abstract class AbstractEntity(
        @JsonProperty("_id")
        var id: String? = null,
        @JsonProperty("_rev")
        var revision: String? = null
)

I get:

org.ektorp.DbAccessException: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "_id" (class com.scherule.calendaring.domain.Meeting), not marked as ignorable

The question is in what way the first code snippet is different from the second? In the first case Ektorp "thinks" there is a mutator but not in the second...

Here's the code snippet which Ektorp seems to use when locating a method (setId, setRevision).

private Method findMethod(Class<?> clazz, String name,
                Class<?>... parameters) throws Exception {
            for (Method me : clazz.getDeclaredMethods()) {
                if (me.getName().equals(name)
                        && me.getParameterTypes().length == parameters.length) {
                    me.setAccessible(true);
                    return me;
                }
            }
            return clazz.getSuperclass() != null ? findMethod(
                    clazz.getSuperclass(), name, parameters) : null;
        }

score 1 · Accepted Answer · edited Jun 20 '20 at 09:12

1

The difference is how application of the annotations to properties defined in the class body differs from annotating properties declared in a primary constructor.

See: Annotation Use-site Targets in the language reference:

When you're annotating a property or a primary constructor parameter, there are multiple Java elements which are generated from the corresponding Kotlin element, and therefore multiple possible locations for the annotation in the generated Java bytecode.

If you don't specify a use-site target, the target is chosen according to the @Target annotation of the annotation being used. If there are multiple applicable targets, the first applicable target from the following list is used:

param

property

field

So, when you annotate a property declared in a primary constructor, it's the constructor parameter that by default gets the annotation in the Java bytecode. To alter that, specify the annotation target explicitly, for example:

abstract class AbstractEntity(
    @get:JsonProperty("_id")
    val id: String? = null,
    @get:JsonProperty("_rev")
    val revision: String? = null
)

edited Jun 20 '20 at 09:12

Community

1
1

answered Aug 16 '17 at 14:37

hotkey

140,743
39
371
326

While this solves the issue with var this does not yet explain why using *val* field doesn't produce "Cannot resolve revision mutator" exception while using it in constructor (even with your fix) does... any ideas? Logic would suggest that val should not work as it does not create setter... but it does (when used as a field, not in constructor declaration which make things even more weird) – kboom Aug 16 '17 at 17:45
I haven't worked with this tool, so I can only suppose that it detects a constructor that it can use to create a new object with the updated property values instead of setting the mutable properties, and that's sufficient. – hotkey Aug 16 '17 at 18:20
Except it works the other way round - it only works if I use fields declaration (outside constructor) - but still "val". Anyway right, this must be more of ektorp lib implementation detail... – kboom Aug 16 '17 at 19:07

Kotlin mutators

1 Answers1