JPOX
JPOX
 Project  |  Ver 1.1  |  Ver 1.2  |  JDO  |  JPA  |  Guides  |  Tools
1.2 | Persistence | JDO ORM | JPA ORM | Runtime | JDO Runtime | JPA Runtime | Extensions | Developer
Persistence
Object Identity
Supported Java Types

When persisting a class, a persistence solution needs to know how to persist the types of each field in the class. Clearly a persistence solution can only support a finite number of Java types. It cannot know how to persist every possible type creatable. The JDO/JPA specifications define lists of types that are required to be supported by all implementations of those specifications. This support can be conveniently split into two parts

  • An object that can be referred-to (object reference, providing a relation) and that has an "identity" - First Class Object (FCO). JDO2 requires an implementation to support PersistenceCapable types, as well as object/interface fields that refer to PersistenceCapable objects. JPA1 requires support for fields that are entity types. JPOX provides support for JDO2/JPA1 FCOs
  • An object that does not have an "identity" - Second Class Object (SCO). This is something like a String or Date field in a class. It can also be a Collection, that contains other objects. JPOX provides full support for JDO2/JPA1 SCOs, as well as support for many more types. Indeed, if the type that you want to persist (as "SCO") is not listed below you can always add support for it via a JPOX plugin using the User-Types Plugin guide


Supported First-Class (FCO) Types

JPOX currently supports objects that are PersistenceCapable as FCO. In addition it supports persisting fields of Interface or java.lang.Object type as FCO (since these are just references to PersistenceCapable objects).



Supported Second-Class (SCO) Types

The table below shows the currently supported SCO java types in JPOX (and the specifications requiring its support). The table also shows the default-fetch-group (DFG) setting for that Java type (so whether it is retrieved by default when retrieving an object with a field of that type), whether the field is persisted by default (if it is "false" then you would have to add persistence-modifier="persistent" to the field for it to be persisted by JDO), and whether the java type is replaced by a wrapper (or proxy) type that intercepts all methods that change the object internally (this is used for dirty detection, and is most common with collections/maps. You will see no difference when using the field of this type. The final column lists the JPOX jar where you will find support for this type

Java TypeSpec.DFG?Persistent?Proxied?PK?Location
booleanjpox-core
bytejpox-core
charjpox-core
doublejpox-core
floatjpox-core
intjpox-core
longjpox-core
shortjpox-core
boolean[]jpox-core
byte[]jpox-core
char[]jpox-core
double[]jpox-core
float[]jpox-core
int[]jpox-core
long[]jpox-core
short[]jpox-core
java.lang.Booleanjpox-core
java.lang.Bytejpox-core
java.lang.Characterjpox-core
java.lang.Doublejpox-core
java.lang.Floatjpox-core
java.lang.Integerjpox-core
java.lang.Longjpox-core
java.lang.Shortjpox-core
java.lang.Boolean[]jpox-core
java.lang.Byte[]jpox-core
java.lang.Character[]jpox-core
java.lang.Double[]jpox-core
java.lang.Float[]jpox-core
java.lang.Integer[]jpox-core
java.lang.Long[]jpox-core
java.lang.Short[]jpox-core
java.lang.Number [4]jpox-core
java.lang.Objectjpox-core
java.lang.Stringjpox-core
java.lang.StringBuffer [3]jpox-core
java.lang.String[]jpox-core
java.math.BigDecimaljpox-core
java.math.BigIntegerjpox-core
java.math.BigDecimal[]jpox-core
java.math.BigInteger[]jpox-core
java.sql.Datejpox-core
java.sql.Timejpox-core
java.sql.Timestampjpox-core
java.util.ArrayListjpox-core
java.util.BitSetjpox-core
java.util.Calendarjpox-core
java.util.Collectionjpox-core
java.util.Currencyjpox-core
java.util.Datejpox-core
java.util.Date[]jpox-core
java.util.GregorianCalendar [7]jpox-core
java.util.HashMapjpox-core
java.util.HashSetjpox-core
java.util.Hashtablejpox-core
java.util.LinkedHashMap [5]jpox-core
java.util.LinkedHashSet [6]jpox-core
java.util.LinkedListjpox-core
java.util.Listjpox-core
java.util.Localejpox-core
java.util.Locale[]jpox-core
java.util.Mapjpox-core
java.util.Propertiesjpox-core
java.util.PriorityQueuejpox-core
java.util.Queuejpox-core
java.util.Setjpox-core
java.util.SortedMap [2]jpox-core
java.util.SortedSet [1]jpox-core
java.util.Stackjpox-core
java.util.TimeZonejpox-core
java.util.TreeMap [2]jpox-core
java.util.TreeSet [1]jpox-core
java.util.UUIDjpox-core
java.util.Vectorjpox-core
java.awt.Colorjpox-core
java.awt.Pointjpox-core
java.awt.image.BufferedImagejpox-core
java.net.URIjpox-core
java.net.URLjpox-core
java.io.Serializablejpox-core
javax.jdo.spi.PersistenceCapablejpox-core
javax.jdo.spi.PersistenceCapable[]jpox-core
java.lang.Enumjpox-java5
java.lang.Enum[]jpox-java5
  • [1] - java.util.SortedSet, java.util.TreeSet allow the specification of comparators via the "comparator-name" JPOX extension MetaData element (within <collection>). The headSet, tailSet, subSet methods are only supported when using cached collections.
  • [2] - java.util.SortedMap, java.util.TreeMap allow the specification of comparators via the "comparator-name" JPOX extension MetaData element (within <map>). The headMap, tailMap, subMap methods are only supported when using cached containers.
  • [3] - java.lang.StringBuffer dirty check mechanism is limited to immutable mode, it means, if you change a StringBuffer object field, you must reassign it to the owner object field to make sure changes are propagated to the database.
  • [4] - java.lang.Number will be stored in a column capable of storing a BigDecimal, and will store to the precision of the object to be persisted. On reading back the object will be returned typically as a BigDecimal since there is no mechanism for determing the type of the object that was stored.
  • [5] - java.util.LinkedHashMap treated as a Map currently. No List-ordering is supported.
  • [6] - java.util.LinkedHashSet treated as a Set currently. No List-ordering is supported.
  • [7] - java.util.Calendar can be stored into two columns (millisecs, Timezone) or into a single column (Timestamp). The single column option is not guaranteed to preserve the TimeZone of the input Calendar.

User-contributed types are available below

  • JodaTime : support is available here - provided by Richard Bolkey



Supported Spatial Types

The table below shows the currently supported Spatial SCO in JPOX. Please refer to the Spatial Types guide for full details

Java TypeSpec.DFG?Persistent?Proxied?PK?Location
oracle.spatial.geometry.JGeometry [1]jpox-spatial
com.vividsolutions.jts.geom.Geometry [1]jpox-spatial
com.vividsolutions.jts.geom.GeometryCollection [1]jpox-spatial
com.vividsolutions.jts.geom.LinearRing [1]jpox-spatial
com.vividsolutions.jts.geom.LineString [1]jpox-spatial
com.vividsolutions.jts.geom.MultiLineString [1]jpox-spatial
com.vividsolutions.jts.geom.MultiPoint [1]jpox-spatial
com.vividsolutions.jts.geom.MultiPolygon [1]jpox-spatial
com.vividsolutions.jts.geom.Point [1]jpox-spatial
com.vividsolutions.jts.geom.Polygon [1]jpox-spatial
org.postgis.Geometry [1]jpox-spatial
org.postgis.GeometryCollection [1]jpox-spatial
org.postgis.LinearRing [1]jpox-spatial
org.postgis.LineString [1]jpox-spatial
org.postgis.MultiLineString [1]jpox-spatial
org.postgis.MultiPoint [1]jpox-spatial
org.postgis.MultiPolygon [1]jpox-spatial
org.postgis.Point [1]jpox-spatial
org.postgis.Polygon [1]jpox-spatial
org.postgis.PGbox2d [1]jpox-spatial
org.postgis.PGbox3d [1]jpox-spatial
  • Dirty check mechanism is limited to immutable mode, it means, if you change a field of one of these spatial objects, you must reassign it to the owner object field to make sure changes are propagated to the database.