Updated documentation

website/src/changelog.md

@@ -10,6 +10,7 @@ changelog:
         - "[#28](https://github.com/Mr-Mappie/mappie/issues/28) added implicit mapping inference of mappers with the same name but a different type, but a mapper for those types are defined."
         - "[#42](https://github.com/Mr-Mappie/mappie/issues/42) added a configuration option to disable resolving via default arguments."
         - "[#40](https://github.com/Mr-Mappie/mappie/issues/40) added `to` alias to refer to for target properties as an alternative to the fully written out `TO` type."
+        - "[#46](https://github.com/Mr-Mappie/mappie/issues/46) added support for Java object getters."
         - "Several other bug fixes."
     - date: "2024-06-27"
       title: "v0.2.0"

website/src/posts/object-mapping/posts/resolving.md

@@ -118,4 +118,13 @@ object PersonMapper : ObjectMappie<Person, PersonDto>() {
     }
 }
 ```
-where `to::streetname` is equivalent to `PersonDto::streetname`.
+where `to::streetname` is equivalent to `PersonDto::streetname`.
+
+## Java Compatibility
+Java classes are different from those of Kotlin. The main difference for Mappie is that Java does not have the concept
+of properties. Instead, the convention is to have a field `x`, and a getter `getX()` and setter `setX(Person value)` 
+method.
+
+Mappie automatically infers such getter methods. They must follow the convention `getX()` for the property `x` to be
+inferred. Also note that in Java all types are nullable. Mappie will give a warning if a Java getter is used to assign
+to a non-nullable target.