Classes without default constructor
Abstract classes / Interfaces
Perfectly handleable as types, but there can never be instances to be persisted in the first place.
Not supported since they are outside of an entity graph / a database, i.e. potentially shared by multiple graphs.
No sense in persisting those. These are just plain trivial values outside of an entity graph / a database.
Must be registered for loading to update them instead of creating independent new instances.
Technically the same as object arrays as every array is an object itself.
JDK value types
(String, Number types, Date, File, Locale, Optional, ...)
Optimized handling via custom TypeHandlers.
Via generic handling logic (List, Set, Map, etc.).
Optimal handling required tailored TypeHandler (e.g. correctly handling loadFactor in java.util.HashMap)
JVM system-tied classes
(Thread, ClassLoader, WeakReference, ...)
Technically handleable, but handling system-instances could cause fatal problems (e.g. start a Thread just from loading data), so it is intentionally disabled.
JVM external-tied classes
(IO-Streams, FileChannel, ...)
Technically handleable, but external dependencies could cause fatal problems (e.g. existence of a referenced file), so it is intentionally disabled.