[
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306553#comment-16306553
]
Rick Hillegas edited comment on DERBY-6945 at 12/29/17 9:29 PM:
----------------------------------------------------------------
Thanks Bryan for continuing to help me puzzle through this.
BP> If you were to step back, at this point in the process,
BP> how would you assess where we are, what we've done
BP> so far, and what lies ahead?
When the derby-6945-08 patch is done, the following should be true. That is, I
expect that we will have achieved the original goal 3 as stated at
https://issues.apache.org/jira/browse/DERBY-6945?focusedCommentId=16265882&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16265882
S1) No classes are duplicated in more than one jar file.
S2) org.apache.derby.jdbc will be the only code package which straddles two jar
files.
S3) All of the shared code should be located in the source tree under
java/shared.
I would like to continue cleaning up the artifacts before adding module
descriptors. Here are the remaining cleanup tasks:
C1) Some classes may need to be moved to different places in the source tree. I
think that the mis-placed code is largely in the optionaltools area. I would
like to achieve the following structure, which a developer can understand at a
glance:
{noformat}
|------------------------|------------------|
| artifact | source code root |
|------------------------|------------------|
| derby.jar | java/engine |
|------------------------|------------------|
| derbynet.jar | java/drda |
|------------------------|------------------|
| derbyoptionaltools.jar | java/optional |
|------------------------|------------------|
| derbyrun.jar | java/run |
|------------------------|------------------|
| derbyshared.jar | java/shared |
|------------------------|------------------|
| derbytools.jar | java/tools |
|------------------------|------------------|
{noformat}
C2) Some resources (static and generated) may need to be moved into a namespace
which fits the pattern sketched above. In particular, I am thinking about the
info.properties files used by sysinfo and about the message localizations.
C3) Figure out what to do about org.apache.derby.jdbc.
C4) Simplify the jar-file-building targets and eliminate the classlister and
jardriftcheck logic. Those two tools are needed currently because you can't
tell at a glance that jar files contain the correct code.
C5) Enable the new VetJigsawTest. I think that this test will be better than
jardriftcheck as a comprehensive measure of our jar files' coherence.
Once that cleanup is done, I hope that we will have achieved the original goals
2 and 4 as stated at
https://issues.apache.org/jira/browse/DERBY-6945?focusedCommentId=16265882&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16265882
and we will be able to move on to defining module boundaries:
J1) Add module descriptors and compile against them.
J2) Annotate the jar file MANIFESTs with module descriptors.
J3) Write regression tests to verify that modules are delivering the expected
encapsulation-based security.
J4) Consider adding sub-modules and aggregator modules.
After that, there will be various documentation tasks:
D1) Add overview sections to the public api and to the engine javadoc. The
overview sections will explain the module structure.
D2) Write a detailed release note.
At that point, I believe that we can declare victory on the original goal 1 as
stated at
https://issues.apache.org/jira/browse/DERBY-6945?focusedCommentId=16265882&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16265882
BP> From my perspective, you've done some very successful
BP> refactoring, and I really appreciate and am grateful for the
BP> effort to clean up the complexity that we once introduced
BP> in order to enable the 'derbyshared' classes, but I'm still
BP> not sure if we know enough about the Java 9 Module
BP> system to be able to clearly describe the final goal.
Java 9 introduces a new build tool, jlink. It packages up a set of modules into
an executable image, similar to the linking phase of C programs. The idea is
that a Java application can be shipped as a standalone executable which runs
even on platforms which don't already have a JRE installed. This is how you
would build an application for Mac OSX or iOS, now that Apple doesn't supply a
JRE by default.
The low bar goal is:
G1) Jlink - Support the jlink'ing of Derby-powered applications.
In addition, I want to use Jigsaw to achieve the following other benefits:
G2) Increased security - Use module encapsulation to reduce Derby's attack
surface. Prevent malware from directly accessing Derby internal's apis.
G3) Reduced footprint - Reduce the size of embedded Derby applications which
need to run on resource-constrained devices. As a consequence, reduce the time
that it takes to boot an embedded Derby application.
BP> My own expectation is that we will work our way around to
BP> packaging Derby as a single jar file, and that will be just
BP> fine, and simpler in many ways, as I think that Java platforms
BP> have evolved a LOT in 20 years, and the needs that drove
BP> us to have half-a-dozen separate configurations and packages
BP> are no longer as interesting now as they once were.
That may be. I may be stuck on an obsolete model about how to build
lightweight, data-rich applications which run on limited hardware. Certainly
there is a lot of momentum behind the current understanding of Cloud as a
remote data black hole. Maybe I'm still clinging to Cloudscape's original
vision of the Cloud as a swarm of independent but cooperating devices.
was (Author: rhillegas):
Thanks Bryan for continuing to help me puzzle through this.
BP> If you were to step back, at this point in the process,
BP> how would you assess where we are, what we've done
BP> so far, and what lies ahead?
When the derby-6945-08 patch is done, the following should be true. That is, I
expect that we will have achieved the original goal 3 as stated at
https://issues.apache.org/jira/browse/DERBY-6945?focusedCommentId=16265882&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16265882
S1) No classes are duplicated in more than one jar file.
S2) org.apache.derby.jdbc will be the only code package which straddles two jar
files.
S3) All of the shared code should be located in the source tree under
java/shared.
I would like to continue cleaning up the artifacts before adding module
descriptors. Here are the remaining cleanup tasks:
C1) Some classes may need to be moved to different places in the source tree. I
think that the mis-placed code is largely in the optionaltools area. I would
like to achieve the following structure, which a developer can understand at a
glance:
{noformat}
|------------------------|------------------|
| artifact | source code root |
|------------------------|------------------|
| derby.jar | java/engine |
|------------------------|------------------|
| derbynet.jar | java/drda |
|------------------------|------------------|
| derbyoptionaltools.jar | java/optional |
|------------------------|------------------|
| derbyrun.jar | java/run |
|------------------------|------------------|
| derbyshared.jar | java/shared |
|------------------------|------------------|
| derbytools.jar | java/tools |
|------------------------|------------------|
{noformat}
C2) Some resources (static and generated) may need to be moved into a namespace
which fits the pattern sketched above. In particular, I am thinking about the
info.properties files used by sysinfo and about the message localizations.
C3) Figure out what to do about org.apache.derby.jdbc.
C4) Simplify the jar-file-building targets and eliminate the classlister and
jardriftcheck logic. Those two tools are needed currently because you can't
tell at a glance that jar files contain the correct code.
C5) Enable the new VetJigsawTest. I think that this test will be better than
jardriftcheck as a comprehensive measure of our jar files' coherence.
Once that cleanup is done, I hope that we will have achieved the original goals
2 and 4 as stated at
https://issues.apache.org/jira/browse/DERBY-6945?focusedCommentId=16265882&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16265882
and we will be able to move on to defining module boundaries:
J1) Add module descriptors and compile against them.
J2) Annotate the jar file MANIFESTs with module descriptors.
J3) Write regression tests to verify that modules are delivering the expected
encapsulation-based security.
J4) Consider adding sub-modules and aggregator modules.
After that, there will be various documentation tasks:
D1) Add overview sections to the public api and to the engine javadoc. The
overview sections will explain the module structure.
D2) Write a detailed release note.
At that point, I believe that we can declare victory on the original goal 1 as
stated at
https://issues.apache.org/jira/browse/DERBY-6945?focusedCommentId=16265882&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16265882
BP> From my perspective, you've done some very successful
BP> refactoring, and I really appreciate and am grateful for the
BP> effort to clean up the complexity that we once introduced
BP> in order to enable the 'derbyshared' classes, but I'm still
BP> not sure if we know enough about the Java 9 Module
BP> system to be able to clearly describe the final goal.
Java 9 introduces a new build tool, jlink. It packages up a set of modules into
an executable image, similar to the linking phase of C programs. The idea is
that a Java application can be shipped as a standalone executable which runs
even on platforms which don't already have a JRE installed. This is how you
would build an application for Mac OSX or iOS, now that Apple doesn't supply a
JRE by default.
The low bar goal is:
G1) Jlink - Support the jlink'ing of Derby-powered applications.
In addition, I want to use Jigsaw to achieve the following other benefits:
G2) Increased security - Use module encapsulation to reduce Derby's attack
surface. Prevent malware from directly accessing Derby internal's apis.
G3) Reduced footprint - Reduce the size of embedded Derby applications which
need to run on resource-constrained devices. As a consequence, reduce the time
that it takes to boot an embedded Derby application.
BP> My own expectation is that we will work our way around to
BP> packaging Derby as a single jar file, and that will be just
BP> fine, and simpler in many ways, as I think that Java platforms
BP> have evolved a LOT in 20 years, and the needs that drove
BP> us to have half-a-dozen separate configurations and packages
BP> are no longer as interesting now as they once were.
That may be. I may be stuck on an obsolete model about how to build
lightweight, data-rich applications which run on limited hardware. Certainly
there is a lot of momentum behind the current understanding of Cloud as a
remote data black hole. Maybe I'm still clinging to Cloudscape's original
vision of the Cloud as a swarm of independent but cooperating devices.
> 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: derby-6945-01-aa-remove_derbyPreBuild_dep.diff,
> derby-6945-02-ab-newDerbySharedJar.diff,
> derby-6945-02-ac-newDerbySharedJar.diff, derby-6945-03-aa-partitionTest.diff,
> derby-6945-04-aa-moveRunClass.diff,
> derby-6945-05-aa-removeRedundant_Attribute_SQLState.diff,
> derby-6945-06-aa-removeOtherSharedDuplicates.diff,
> derby-6945-07-aa-net_client_overlap.diff,
> derby-6945-08-aa-move_shared_iapi_under_shared.diff,
> derby-6945-08-ab-move_shared_iapi_under_shared.diff,
> derby-6945-08-ad-move_shared_iapi_under_shared.diff, 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)
