db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-6945) Re-package Derby as a collection of jigsaw modules
Date Sat, 25 Nov 2017 23:51:01 GMT

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

Mime
View raw message