Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EclipseLink/DesignDocs/384399"

(Bundle Changes)
m (Document History)
Line 20: Line 20:
 
| 2012/09/13
 
| 2012/09/13
 
| Blaise Doughan
 
| Blaise Doughan
| Rewrite
+
| Updated document to reflect new strategy for reducing MOXy's install footprint.
 
|-
 
|-
 
|
 
|

Revision as of 14:22, 14 September 2012

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/13 Blaise Doughan Updated document to reflect new strategy for reducing MOXy's install footprint.

Project overview

Problem

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.

Concepts

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.

Requirements

  1. Existing bundles must remain binary compatible, except the JAXB impl classes. This means if you only use the java.xml.bind.* classes you will be find, but if you cast down to the org.eclipse.persistence.jaxb.* classes then you may need to make code changes or recompile.

Design / Functionality

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 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

Common Abstractions

The common bundle will include abstractions that are common to both MOXy and ORM. Below is an example of the current and proposed architectures.

  • AbstractProject, AbstractDescriptor, and AbstractMapping would be part of the new common bundle.
  • Project, ClassDescriptor, and DatabaseMapping would be changed to extend their counterparts from the core bundle. This would be done in such a way as to maintain binary compatibility.
  • New MOXy classes would be added (i.e. XMLProject and XMLMapping) and others modified (i.e. XMLDescriptor). This would introduce a binary incompatibility in the native MOXy APIs.
Current (edit) Proposed (edit)
DesignDoc384399-Before.jpg            DesignDoc384399-Proposed.jpg

Medium Level

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

Low Level

Inheritance Hierarchies

To Do

Development Plan

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 Interfaces Into a New org.eclipse.persistence.bind Bundle

The internal.oxm classes and the new common 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

Phase #3 - Implement Light Weight Version of Core Interfaces

A lightweight version of the core 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.

Testing

Binary Compatible Testing

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

API

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 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 interface 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 interfaces (the class names below are for demonstration purposes only). The existing core OXM classes will continue to work (see below).

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

Existing Core Classes (i.e. ClassDescriptor)

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

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

Documentation

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?

Decisions

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

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