Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POJO encoder doesn't handle final fields #77

Open
PeterKelecom opened this issue Aug 26, 2019 · 3 comments
Open

POJO encoder doesn't handle final fields #77

PeterKelecom opened this issue Aug 26, 2019 · 3 comments

Comments

@PeterKelecom
Copy link

PeterKelecom commented Aug 26, 2019

Final fields are ignored in PojoUtils.toMap:

@SneakyThrows
  public static Map<String, Object> toMap (@NonNull Object object) {
    val result = new HashMap<String, Object>();
    val type = object.getClass();
    val setAccessibleAction = new SetAccessibleAction();
    for (val field : type.getDeclaredFields()) {
      val modifiers = field.getModifiers();
      if (isFinal(modifiers) || isStatic(modifiers)) {
        continue;
      }
      setAccessibleAction.setField(field);
      AccessController.doPrivileged(setAccessibleAction);

      val fieldValue = field.get(object);
      if (fieldValue == null) {
        continue;
      }

      val propertyKey = field.isAnnotationPresent(FormProperty.class)
                        ? field.getAnnotation(FormProperty.class).value()
                        : field.getName();

      result.put(propertyKey, fieldValue);
    }
    return result;
  }

This means we can't use data classes in Kotlin. Is there a compelling reason why final fields are being ignored?

@slawekjaranowski
Copy link

can be connected with: #95

@WtfJoke
Copy link

WtfJoke commented Sep 17, 2021

This means we can't use data classes in Kotlin.

You can use them, but you cant use val, just var (valid for both class and data class)

@zarebski-m
Copy link

This has broader consequences: not only final fields are silently ignored, but also it requires all form params to be actual fields. I can imagine a scenario where form param is calculated on the fly and is not backed by any field (e.g. String getFoo() { return "xxx" }. On the other hand, it will send private fields that are not exposed from the class and therefore not a part of it's bean definition; for example Kotlin delegates, etc.

Any reason why param extraction is done this way instead of using standard java.beans.Introspector?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants