known limitations

Type erasure

Random Beans uses the Java Reflection API to introspect the bean type at runtime and generate random data accordingly. There are some cases where Random Beans is not able to get the information required about a class or a field type at runtime. The most obvious use case is generic types. Due to type erasure, generic types are erased at runtime and Random Beans is just unable to get this information. Some related issues to this use case: #19, #242, #311. The suggested way to work around this limitation is to register a custom randomizer for the specific type.

Composite collections

Random Beans does not support composite collections like List<List<String>> or Map<String, List<Integer>>. This is technically possible (even though it's quite hard to imagine all possible combinations and come up with a generic solution) but obviously will make the implementation complex for no real added value. It is always possible to register a custom (collection) randomizer for such types.

Android compatibility

Random Beans is known to not play well with Android. This is due to how Dalvik VM differs from a regular JVM (some Java APIs are missing, byte code difference, etc). More details can be found in the following issues: #62, #270, #303.

Bean Validation

Random Beans can generate random valid data for all Bean Validation API annotations except for @Digits.

Inner classes and static nested classes

Random Beans is able to randomize inner classes as well as static nested classes. However, the constructor of an inner class will not be called as Random Beans is not be able to get this constructor through reflection. In this case, it will fallback to using Objenesis (which will instantiate the inner class without calling the constructor). So if you have some initialization code in the constructor of an inner class, do not expect it to be called. Otherwise, you need to make your inner class as a static nested class for this to work. For more details, take a look at issue #268.