You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <ji...@apache.org> on 2017/11/25 23:51:01 UTC
[jira] [Comment Edited] (DERBY-6945) Re-package Derby as a
collection of jigsaw modules
[ https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265882#comment-16265882 ]
Rick Hillegas edited comment on DERBY-6945 at 11/25/17 11:50 PM:
-----------------------------------------------------------------
Here are my initial thoughts about dividing Derby 10.15 into Jigsaw modules. As I dig into this further, I will share what I learn.
What are your thoughts? Does anyone have different ideas about how Derby splits up into Jigsaw-ready modules?
Thanks,
-Rick
----
h2. Jigsaw Overview
Jigsaw provides tools and abstractions for dividing a software project into versioned components and for declaring how those components depend on one another. These are capabilities previously supplied by frameworks/tools like OSGi and Maven. In addition, Jigsaw enhances the encapsulation provided by the existing public/protected/private/(package) security labels; that is, Jigsaw lets a programmer restrict class visibility to a limited set of outer components (or jar file artifacts). As I understand it, the primary benefits of Jigsaw are:
1. Increased security - as a result of the extra encapsulation.
2. Smaller footprint - The JVM now has clearly defined module boundaries. That means that it can be subsetted. That, in turn, reduces the size of standalone applications, an especially important point for popular small devices.
The following resources are useful for understanding Jigsaw:
* Initial sections of [Mark Reinhold's overview|http://openjdk.java.net/projects/Jigsaw/spec/sotms/]
* Open JDK [project description|http://openjdk.java.net/projects/Jigsaw/]
* Tool for analyzing a project's existing module structure ([jdeps|https://docs.oracle.com/javase/9/tools/jdeps.htm#JSWOR690])
* Consol Labs [tutorial|https://labs.consol.de/development/2017/02/13/getting-started-with-java9-modules.html]
I think that the goals of Derby's modularization should be:
1. Reduce the attack surface of each of the product jars. Expose only essential public api's to being called from outside each jar file.
2. Identify a core of Derby to run on the smallest possible JVM. Probably this is most of the engine jar file.
3. Carve out a new jar file for code currently cloned across multiple jars (largely, the code under java/shared).
4. Avoid splintering Derby into further, tiny micro-artifacts. However, where possible, use Jigsaw to declare the boundaries of micro-artifacts. This would let alternative builds tease out a different set of release targets.
Proposed modules correspond to the current subdirectories under java...
derby.client (derbyclient.jar)
derby.drda (derbynet.jar)
derby.engine (derby.jar)
derby.optional (derbyoptionaltools.jar)
derby.shared (new derbyshared.jar)
derby.testing (derbyTesting.jar)
derby.tools (derbytools.jar)
...plus the language localizations
----
h2. Proposed Modules
I am attaching jdeps.out.tar. This tarball contains jdeps' analysis of Derby's existing code artifacts, that is, the released jar files (excluding the language localizations). For each $jarFile, there is a corresponding $jarFile.dot, which shows how its packages depend on one another. There is also a summary.dot file, which shows how the jars depend on one another.
The proposed Derby modules appear in the following dependency graph. Higher modules depend on lower modules to which they are connected:
{noformat}
derby.optional
/ |
/ |
/ derby.drda |
/ / | |
/ / | |
derby.engine | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
| | derby.client \ | | derby.tools
| | / | \ | | |
| \ / | \ | | |
| \ / | \ | | |
| \ | \ | | |
| \ | \ | | |
| \ --------------------------------------
| \ |
| \ |
| \ / \
| \ / \
| \ / \
| \ derby.shared \
| \ | \
| \ | \
| \ | java.sql
| \ | / |
| \ | / |
| \ | / |
java.management java.naming | java.logging java.xml
| | | | |
| | | | |
| | | | |
_____________|______________|__________|______|____________|
|
|
java.base
{noformat}
Some refactoring will be needed in order to achieve this layering. Hopefully, we will be able to eliminate the following dependencies:
derby.optional
-> derby.client
-> derby.tools
-> not found
derby.tools
-> derby.engine
-> not found
derby.client
-> not found
derby.drda
-> not found
derby.engine
-> not found
was (Author: rhillegas):
Here are my initial thoughts about dividing Derby 10.15 into Jigsaw modules. As I dig into this further, I will share what I learn.
What are your thoughts? Does anyone have different ideas about how Derby splits up into Jigsaw-ready modules?
Thanks,
-Rick
----
h2. Jigsaw Overview
Jigsaw provides tools and abstractions for dividing a software project into versioned components and for declaring how those components depend on one another. These are capabilities previously supplied by frameworks/tools like OSGi and Maven. In addition, Jigsaw enhances the encapsulation provided by the existing public/protected/private/(package) security labels; that is, Jigsaw lets a programmer restrict class visibility to a limited set of outer components (or jar file artifacts). As I understand it, the primary benefits of Jigsaw are:
1. Increased security - as a result of the extra encapsulation.
2. Smaller footprint - The JVM now has clearly defined module boundaries. That means that it can be subsetted. That, in turn, reduces the size of standalone applications, an especially important point for popular small devices.
The following resources are useful for understanding Jigsaw:
* Initial sections of [Mark Reinhold's overview|http://openjdk.java.net/projects/Jigsaw/spec/sotms/]
* Open JDK [project description|http://openjdk.java.net/projects/Jigsaw/]
* Tool for analyzing a project's existing module structure ([jdeps|https://docs.oracle.com/javase/9/tools/jdeps.htm#JSWOR690])
* Consol Labs [tutorial|https://labs.consol.de/development/2017/02/13/getting-started-with-java9-modules.html]
I think that the goals of Derby's modularization should be:
1. Reduce the attack surface of each of the product jars. Expose only essential public api's to being called from outside each jar file.
2. Identify a core of Derby to run on the smallest possible JVM. Probably this is most of the engine jar file.
3. Carve out a new jar file for code currently cloned across multiple jars (largely, the code under java/shared).
4. Avoid splintering Derby into further, tiny micro-artifacts. However, where possible, use Jigsaw to declare the boundaries of micro-artifacts. This would let alternative builds tease out a different set of release targets.
Proposed modules correspond to the current subdirectories under java...
derby.client (derbyclient.jar)
derby.drda (derbynet.jar)
derby.engine (derby.jar)
derby.optional (derbyoptionaltools.jar)
derby.shared (new derbyshared.jar)
derby.testing (derbyTesting.jar)
derby.tools (derbytools.jar)
...plus the language localizations
----
h2. Proposed Modules
I am attaching jdeps.out.tar. This tarball contains jdeps' analysis of Derby's existing code artifacts, that is, the released jar files (excluding the language localizations). For each $jarFile, there is a corresponding $jarFile.dot, which shows how its packages depend on one another. There is also a summary.dot file, which shows how the jars depend on one another.
The proposed Derby modules appear in the following dependency graph. Higher modules depend on lower modules to which they are connected:
{noformat}
derby.optional
/ |
/ |
/ derby.drda |
/ / | |
/ / | |
derby.engine | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
/ / \ | |
| | derby.client \ | | derby.tools
| | / | \ | | |
| \ / | \ | | |
| \ / | \ | | |
| \ | \ | | |
| \ | \ | | |
| \ --------------------------------------
| \ |
| \ |
| \ / \
| \ / \
| \ / \
| \ derby.shared \
| \ | \
| \ | \
| \ | java.sql
| \ | / |
| \ | / |
| \ | / |
java.management java.naming | java.logging java.xml
| | | | |
| | | | |
| | | | |
_____________|______________|__________|______|____________|
|
|
java.base
{noformat}
Some refactoring will be needed in order to achieve this layering. Hopefully, we will be able to eliminate the following dependencies:
derby.optional
-> derby.client
-> derby.tools
-> not found
derby.tools
-> derby.engine
-> not found
derby.client
-> not found
derby.drda
-> not found
derby.engine
-> not found
> Re-package Derby as a collection of jigsaw modules
> --------------------------------------------------
>
> Key: DERBY-6945
> URL: https://issues.apache.org/jira/browse/DERBY-6945
> Project: Derby
> Issue Type: Improvement
> Affects Versions: 10.13.1.2
> Reporter: Rick Hillegas
> Attachments: jdeps.out.tar
>
>
> Once we commit to building with Java 9 (see DERBY-6856), we should consider re-packaging Derby as a set of jigsaw modules. This would result in a different set of release artifacts. This might be a good opportunity to address the Tomcat artifactory issues raised by issue DERBY-6944.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)