Skip to main content
Jump to: navigation, search


< EclipseLink‎ | DesignDocs
Revision as of 14:13, 5 November 2012 by (Talk | contribs) (Public Classes)


Design Specification: MOXy Footprint Reduction

ER 384399

Document History

Date Author Version Description & Notes
2012/07/05 Blaise Doughan Initial draft
2012/08/20 Blaise Doughan Pre-review Draft
2012/09/17 Blaise Doughan Updated document to reflect new strategy for reducing MOXy's install footprint.
2012/09/21 Blaise Doughan Updated document based on feed back from design review on 2012/09/19
2012/09/24 Blaise Doughan Review Version
2012/11/05 Blaise Doughan Progress Update

Project overview


The install footprint is currently preventing MOXy from being bundled with other software and used on mobile platforms.

XML Binding Install Footprint (EclipseLink 2.4)

Bundle Size
org.eclipse.persistence.moxy_2.4.0.v20120608-r11652.jar 455 KB
org.eclipse.persistence.asm_3.3.1.v201206041142.jar 271 KB
org.eclipse.persistence.core_2.4.0.v20120608-r11652.jar 4711 KB
5437 KB

JSON Binding Install Footprint (EclipseLink 2.4)

Bundle Size
org.eclipse.persistence.moxy_2.4.0.v20120608-r11652.jar 455 KB
org.eclipse.persistence.asm_3.3.1.v201206041142.jar 271 KB
org.eclipse.persistence.core_2.4.0.v20120608-r11652.jar 4711 KB
org.eclipse.persistence.antlr_3.2.0.v201206041011.jar 190 KB
5627 KB

Primary Goals

Reduce the size of X so that is no more that 600 KB.

Bundle Size
org.eclipse.persistence.moxy_2.4.0.v20120608-r11652.jar 455 KB
org.eclipse.persistence.asm_3.3.1.v201206041142.jar 271 KB
org.eclipse.persistence.oxm_2.4.0.v20120608-r11652.jar X KB
org.eclipse.persistence.antlr_3.2.0.v201206041011.jar 190 KB
(726 + X) KB (XML) / (916 + X) KB (JSON)

Secondary Goals

Memory Improvement

Many of the current "core" classes contains information that is only required for object-relational mapping. This type of metadata needlessly increases the amount of memory MOXy requires to run. This refactor will reduce the amount of memory MOXy requires to run.


Package Splitting

This is when classes from the same package are distributed among different bundles. Modularity frameworks discourage splitting packages and therefore is something that we can not do.

Backwards Compatibility

Support applications written/compiled against previous versions of EclipseLink. Failing to be backwards compatible will have a negative impact on our user base. Anything less than binary compatibility will affect applications that include EclipseLink.

Binary Compatible

Applications compiled against EclipseLink before the footprint reduction will continue to work against EclipseLink after the footprint reduction.

Source Code Compatible

Applications compiled against EclipseLink before the footprint reduction will not continue to work against EclipseLink after the footprint reduction. The user won't need to modify their source code, but they will need to recompile it against the new version of EclipseLink.


The user would need to make changes to their code to work with the new version of EclipseLink. We could leverage the "package renamer" tool to make it easier for users to migrate their code to the new APIs.

Generics & Parameterized Types

This design makes use of generics, below is an example if you are not familiar with the mechanism in Java.

package demo;
import java.lang.reflect.Method;
public class Demo {
	private static String METHOD_NAME = "sample";
	private static Class<?>[] PARAMETER_TYPES = new Class[] {String.class};
	public static void main(String[] args) throws Exception {
		// Use Method - Test Method Can Be Called
		Integer a = new Foo().sample("A"); // YES
		Integer b = new Bar().sample("B"); // YES
		Integer c = new Baz().sample("C"); // YES
		// Reflection - Test Method Accessed Via Reflection
		hasMethod(Foo.class, METHOD_NAME, PARAMETER_TYPES); // YES
		hasMethod(Bar.class, METHOD_NAME, PARAMETER_TYPES); // NO
		hasMethod(Baz.class, METHOD_NAME, PARAMETER_TYPES); // YES
	private static void hasMethod(Class<?> clazz, String methodName, Class<?>[] parameterTypes) {
		try {
			Method method = clazz.getMethod(methodName, parameterTypes);
		} catch(NoSuchMethodException e) {
	// Regular Java Class
	static class Foo {
		public Integer sample(String string) {
			return null;
	// Parameterized Type
	static abstract class AbstractBar<RETURN, PARAMETER> {
		private RETURN value;
		public RETURN sample(PARAMETER parameter) {
			return value;
	// Subclass of Parameterized type
	static class Bar extends AbstractBar<Integer, String>{
	// Subclass of Parameterized type that overrides method from super class
	static class Baz extends AbstractBar<Integer, String> {
		public Integer sample(String parameter) {
			return super.sample(parameter);

MOXy's DOM & SAX Platforms

MOXy contains two object-to-XML implementations: DOMPlatform and SAXPlatform. DOMPlatform was the first implementation and closely mirrors the mechanisms used by EclipseLink's object-to-relational mapping. SAXPlatform was introduced second as a performance improvement and now has almost completely replaced all usages of DOMPlatform.


  1. Existing classes must remain binary compatible. This means that applications compiled against a previous version of EclipseLink must continue to run against the version of EclipseLink that implements the footprint reduction. Breaking backwards (binary) compatibility would require us to due a whole number version increment (i.e. 2.4.-> 3.0 and not 2.4 -> 2.5).


New Core Abstractions

The following are core classes that are required by MOXy. These classes currently have dependencies on other ORM specific classes. As part of this feature new super classes will be created for each of these classes to contain the shared behaviour and state. The abstractions will maintain the same package structure under:

  • org.eclipse.persistence.core
  • org.eclipse.persistence.internal.core

Public Classes

This refactoring will affect the following public classes. Binary compatibility will be maintained as a result of this refactoring.

  • org.eclipse.persistence.descriptors.ClassDescriptor
  • org.eclipse.persistence.descriptors.DescriptorEvent
  • org.eclipse.persistence.descriptors.DescriptorEventManager
  • org.eclipse.persistence.descriptors.InheritancePolicy
  • org.eclipse.persistence.mappings.DatabaseMapping
  • org.eclipse.persistence.mappings.converters.Converter
  • org.eclipse.persistence.sessions.Session

Internal Classes

This refactoring will affect the following internal classes. Even though these classes are technically internal they are probably leveraged by some of our users so binary compatibility will be maintained for these classes as well.

  • org.eclipse.persistence.internal.databaseaccess.Platform
  • org.eclipse.persistence.internal.descriptors.ObjectBuilder
  • org.eclipse.persistence.internal.helper.ClassConstants
  • org.eclipse.persistence.internal.helper.ConversionManager
  • org.eclipse.persistence.internal.helper.DatabaseField
  • org.eclipse.persistence.internal.helper.Helper
  • org.eclipse.persistence.internal.sessions.AbstractRecord
  • org.eclipse.persistence.internal.sessions.AbstractSession

Areas Where We Need to Duplicate Code

Possible Approaches

Option #1 - Move ORM Specific Packages to JPA Bundle

Using the Class Dependency Analyzer (CDA) tool I was able to determine that the following packages could be removed from the core bundle without affecting MOXy. Since we cannot split packages only whole packages can be moved. The classes in these packages represent approximately 170 KB of the core bundle.

  • org/eclipse/persistence/expressions/spatial
  • org/eclipse/persistence/internal/jpa/jpql
  • org/eclipse/persistence/platform/server/glassfish
  • org/eclipse/persistence/platform/server/jboss
  • org/eclipse/persistence/platform/server/oc4j
  • org/eclipse/persistence/platform/server/sap
  • org/eclipse/persistence/platform/server/sunas
  • org/eclipse/persistence/platform/server/was
  • org/eclipse/persistence/platform/server/wls
  • org/eclipse/persistence/services/glassfish
  • org/eclipse/persistence/services/jboss
  • org/eclipse/persistence/services/weblogic
  • org/eclipse/persistence/tools/file
  • org/eclipse/persistence/transaction
  • org/eclipse/persistence/transaction/glassfish
  • org/eclipse/persistence/transaction/jboss
  • org/eclipse/persistence/transaction/jotm
  • org/eclipse/persistence/transaction/oc4j
  • org/eclipse/persistence/transaction/sap
  • org/eclipse/persistence/transaction/sunas
  • org/eclipse/persistence/transaction/was
  • org/eclipse/persistence/transaction/wls

Enhancement Request (Contains Patch)

Footprint Reduction

Approximately 170 KB

Option #2 - Refactor OXM Layer

In this option the OXM classes will be refactored to reduce the dependencies. Since the DOMPlatform is no longer used this support could be dropped.


Option #3 - Fork OXM/JAXB Layers

In order to maintain | binary compatibility a new lighter weight MOXy will be created. This will leave the existing APIs to preserve compatibility.


  • Interfaces and abstract classes will be created to represent functionality common to core OXM and ORM behaviour.
  • Private OXM classes will be modified to interact with the new common interfaces/classes.
  • Existing core classes will implement/extend the new common interfaces/classes.
  • New MOXy classes will be created that implement the new common interfaces/classes.

Design / Functionality

The following covers how approach #3 could be accomplished.

High Level

MOXy contains two mechanisms for converting objects to/from XML: DOMPlatform and SAXPlatform. DOMPlatform has strong roots in ORM processing (supports queries, change sets, etc) and is leveraged by EclipseLink EIS. SAXPlatform was introduced to optimize the binding use case as part of the JAXB implementation. The SAXPlatform shares much less logic with the ORM layer than the DOMPlatform does, but shares all the same dependencies. The goal of this feature is to extract only the code necessary to make the SAXPlatform work in order to support the JAXB use case.

Bundle Changes

  1. Introduce a new org.eclipse.persistence.bind bundle to contain common classes and interfaces and the light-weight OXM implementation.
  2. Modify the core bundle to depend on the new bind bundle.
  3. Move MOXy specify items from core into MOXy bundle
  4. Move old OXM code into separate bundle for backwards compatibility

Common Abstractions

A true common core will be created to represent the common behaviour between OXM and ORM. This common core will consist of both interfaces and abstract classes.

Abstract Classes

Where possible common behaviour will be represented as abstract classes. This allows real code to be shared between the ORM and OXM layers. To preserve binary backwards compatibility where the current ORM classes are modified to extend the new abstract classes they will need a method with the correct method signature that simply calls/returns the super method.

It will be possible to introduce abstract classes where there is a shared concept that isn't part of an inheritance hierarchy (i.e. Project, Descriptor, Mapping).

  • AbstractProject, AbstractDescriptor, and AbstractMapping would be new abstract classes to represent common functionality.
  • Project, ClassDescriptor, and DatabaseMapping would be changed to extend their counterparts from the common abstract classes. This would be done in such a way as to maintain binary compatibility.
  • A new lightweight MOXy implementation of these classes would be created.

Current (edit) Proposed (edit)
DesignDoc384399-Before.jpg            DesignDoc384399-Proposed.jpg


Where the concept is an inheritance hierarchy (i.e. ContainerPolicy, InterfaceContainerPolicy, MapContainer) interfaces will need to be used instead of abstract classes.

Required Abstractions

Initial prototyping indicates that abstractions would be required for the following classes:

  • org.eclipse.persistence.config
    • DescriptorCustomizer
  • org.eclipse.persistence.descriptors
    • ClassDescriptor
    • ClassExtractor
    • DescriptorEvent
    • DescriptorEventAdapter
    • DescriptorEventAdapter
    • DescriptorEventManager
    • InheritancePolicy
    • InstatiationPolicy
  • org.eclipse.persistence.exceptions
    • ExceptionHandler
    • IntegrityChecker
  • org.eclipse.persistence.internal.databaseaccess
    • DatasourcePlatform
  • org.eclipse.persistence.internal.descriptors
    • ObjectBuilder
  • org.eclipse.persistence.internal.helper
    • ConversionManager
    • DatabaseField
    • DatabaseTable
  • org.eclipse.persistence.internal.identitymaps
    • CacheKey
  • org.eclipse.persistence.internal.queries
    • ContainerPolicy
  • org.eclipse.persistence.internal.sessions
    • AbstractRecord
    • AbstractSession
    • IdentityMapAccessor
  • org.eclipse.persistence.mappings
    • AttributeAccessor
    • DatabaseMapping
  • org.eclipse.persistence.mappings.converters
    • Converter
  • org.eclipse.persistence.mappings.sessions
    • DatasourceLogin
  • org.eclipse.persistence.queries
    • ObjectBuildingQuery
  • org.eclipse.persistence.sessions
    • Project
    • SessionEvent
    • SessionEventAdapter
    • SessionEventListener
    • SessionEventManager
    • SesssionLog

Development Plan

Below is what the development plan would look like if we decide to maintain binary backwards compatibility of the native OXM APIs (see Open Issue #2).

Phase #1 - Introduce Core Interfaces Required by internal.oxm Packages

Much of the processing for the SAXPlatform is done in the internal.oxm packages. Where this logic depends on core classes interfaces will be created an the interanl.oxm logic will be updated to use the new interfaces instead. The core classes will be updated to implement/extend the new interfaces so that all current code continues to run.

Phase #2 - Pull internal.oxm Classes and Common Classes/Interfaces Into a New org.eclipse.persistence.bind Bundle

The internal.oxm classes and the new common classes/interfaces will form the basis of a new org.eclipse.persistence.bind bundle. The core bundle will be dependent on this new bundle. During this move the XML prefix on class names will be dropped, and the internal.oxm package will be renamed internal.bind. This is to reflect that MOXy now supports more than just object-to-XML mapping (MOXy also supports object-to-JSON mapping).

Phase #3 - Implement Light Weight Version of Core Classes/Interfaces

A lightweight version of the core classes/interfaces will be implemented in the org.eclipse.persistence.bind package. Where possible the corresponding implementations in the org.eclipse.persistence.oxm package will be updated to extend their counterparts in the bind bundle so that there is as little code duplication as possible.

Phase #4 - Update MOXy JAXB to Use org.eclipse.persistence.bind Bundle

Switch MOXy JAXB to use the bind bundle.

Phase #5 (Optional) - Update SDO to Use org.eclipse.persistence.bind Bundle

Switch SDO to use the bind bundle. We may or may not want to introduce a binary incompatibility into the SDO implementation by making this change.

Phase #6 (Optional) - Update Core to Use org.eclipse.persistence.bind Bundle

Switch core to use the bind bundle.

Phase #7 (Optional) - Move org.eclipse.persistence.oxm Classes into an oxm Bundle

Once the core bundle is no longer dependent upon the oxm classes they could be moved into there own bundle. This would reduce the footprint of the core bundle. The oxm classes would still be available for anyone that required them for backwards compatibility reasons.


Binary Compatible Testing

Testing would be required to ensure that binary compatibility is kept, for the areas we plan on maintaining binary compatibility.


Core Packages

The common core classes will be under the following package. The final package structure will be reviewed once all the abstractions are known.

  • org.eclipse.persistence.internal.core

Proposed Class Structure

New Abstractions (i.e. Descriptor)

A set of classes/interfaces will be created to represent the core functionality that is common to both object-to-XML and object-to-relational mapping. Type variables will be leveraged so that the OXM and ORM implementations can be further specialized.

package org.eclipse.persistence.internal.core;
public abstract class Descriptor<
    OBJECT_BUILDER extends ObjectBuilder,
    INHERITANCE_POLICY extends InheritancePolicy,
    INSTANTIATION_POLICY extends InstantiationPolicy> {
    OBJECT_BUILDER getObjectBuilder();
    INHERITANCE_POLICY getInheritancePolicy();
    INSTANTIATION_POLICY getInstantiationPolicy();

New OXM Classes

The new light weight MOXy will provide a new implementation of these core classes/interfaces (the class names below are for demonstration purposes only). The existing core OXM classes will continue to work (see below).

public class SmallXMLDescriptor extends Descriptor<SmallObjectBuilder, SmallInheritancePolicy, SmallInstantiationPolicy>, Cloneable, Serializable {

Existing Core Classes (i.e. ClassDescriptor)

The existing core classes will be modified to extends/implement these classes/interfaces supplying the appropriate type variables. Everything else about the core classes will stay the same ensuring backwards compatibility.

public class ClassDescriptor extends Descriptor<ObjectBuilder, InheritancePolicy, InstantiationPolicy>, Cloneable, Serializable {


The following items will need to be documented:

  • What the binary incompatibilities are (if any).

Open Issues

This section lists the open issues that are still pending that must be decided prior to fully implementing this project's requirements.

Issue # Owner Description / Notes
1 Doug/Peter Does the implementation of this feature require us to bump the version number to 3.0?
2 Doug/Peter/Blaise Do we need to maintain binary compatibility of the native OXM APIs?


This section lists decisions made. These are intended to document the resolution of open issues or constraints added to the project that are important.

Issue # Description / Notes Decision

Future Considerations

Remove Need for ASM Bundle

There are a few areas where MOXy makes use of the ASM bundle to generate bytecodes. Some feature work could be done to eliminate the need to generate these bytecodes and the ASM dependency could be dropped removing it from the install footprint.

Remove Need for ANTLR Bundle

Currently the ANTLR bundle is required to parse JSON documents. Once a standard JSON parser is available (see [1]), we can remove dependency on ANTLR from MOXy.

Project Jigsaw

Is a standard module system being designed for the Java SE platform. It is being applied to the JDK itself. While this feature is not dependent on Jigsaw, care will be taken as to what modules we will need to depend on.

Back to the top