Motivation

Currently, byte[] → BinaryObject → POJO logic, BinaryMarshaller logic are highly coupled with Ignite core codebase.

This restricts Ignite improvement in the following ways:

• Hard to improve, fix any aspect of serdes process. As an example of complexity to add any new BinaryType one can look into BinaryArray implementation
• Can't deliver thin client as tiny jar. Thin client included in ignite-core  module, because, binary infrastracture inside of core.
• Can't be replaced with other implementation, e.g. JSONB

To unlock further improvements of Ignite in this aspects and possibly provide a way to plugin different implementation of Binary serdes (msgpack, jsonb as an examples) we must to refactor Ignite and extract all Binary related classes to separate module

providing clear abstractions and default implementaion.

Description

Two new modules must be created:

• ignite-commons - common Ignite class from packages like `org.apache.ignite.lang`, `org.apache.ignite.internal.util.*` which are used all over codebase.
  • This module required, because of classes like IgniteException , ToStringBuilder , F , U  IgniteClosure  and others used both in thin client and core code. 
• ignite-binary-object-api  - "public" interfaces to be used in ignite code. Here we use term "public" in a sense that other part of Ignite codebase know about those classes, but don't know anything about implementation.
• ignite-binary-object-impl  - implementation of binary infrastructure.

Implementation

Phase#1 Refactoring

1. Moving all required classes to ignite-commons .
2. Assembling module like now - all classes from ignite-commons  are packed in ignite-core.jar.

Phase#2 API Extraction

1. Moving public API to ignite-binary-object-api  which will depends only on ignite-commons .
2. Assembling module like now - all classes from ignite-commons and ignite-binary-object-api are packed in ignite-core.jar.

Phase#3 Impl extraction

1. Moving implementation to ignite-binary-object-impl  which depends only on ignite-commons  and ignite-binary-object-api .
2. Elimination compile time dependency between ignite-core  and ignite-binary-object-impl . ignite-core  knows about ignite-binary-object-api  only.

#	Binary infrastructure public classes	Is part of internal API	Complexity to hide
1	org.apache.ignite.internal.binary.BinaryArray	No	hard
2	org.apache.ignite.internal.binary.BinaryClassDescriptor	No
3	org.apache.ignite.internal.binary.BinaryContext	Yes	-
4	org.apache.ignite.internal.binary.BinaryEnumObjectImpl	No	hard
5	org.apache.ignite.internal.binary.BinaryFieldMetadata	Yes
6	org.apache.ignite.internal.binary.BinaryMarshaller	Yes	-
7	org.apache.ignite.internal.binary.BinaryMetadata	Yes	-
8	org.apache.ignite.internal.binary.BinaryReaderHandles	No	medium
9	org.apache.ignite.internal.binary.BinarySchema	No	medium
10	org.apache.ignite.internal.binary.BinaryTypeImpl	Yes	-
11	org.apache.ignite.internal.binary.BinaryUtils	Yes	-
12	org.apache.ignite.internal.binary.GridBinaryMarshaller	Yes	-

Phase#4 ignite-thin-client extraction

1. Moving IgniteClient, TcpIgniteClient classes with all dependecies to ignite-thin-client module. 
2. ignite-thin-client  must have the following dependencies:
   1. Compile time - ignite-commons , ignite-binary-object-api .
   2. Runtime - ignite-binary-object-impl . 

Risks and Assumptions

IEP concentrated on code structure only and must not break any public benavior or API.

• Does this proposal affect the user in any way?
  • No
• Does it introduce or remove features?
  • No
• Does it affect compatibility?
  • No

Discussion Links

Tickets