[
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16305638#comment-16305638
]
Rick Hillegas commented on DERBY-6945:
--------------------------------------
Via private email, I have sent the following question to Alex Buckley.
Hopefully, he can help us figure out what to do with org.apache.derby.jdbc.
--------------------------
Hey Alex,
I have a jigsaw puzzle, which I hope you can help me solve.
You will recall that I am splitting Apache Derby up into jigsaw modules.
Mostly, this is a straightforward exercise. However, one package is proving to
be problematic. It has the following characteristics:
P1) It contains most of the classes in Derby's public API, that is, the classes
whose usage pattern cannot change, due to Derby's strict backward-compatibility
guarantees.
P2) Unfortunately, it also straddles two jar files. Half of its classes end up
in one jar file and the remainder end up in the other jar. These two artifacts
are Derby's biggest jar files and they roughly correspond to the split between
client and server functionality.
The following clumsy solutions occur to me:
S1) Isolate the problem package in its own jar file. Internally, re-plumb the
classes so that they use reflection in order to instantiate wrapped minions
which forward the public api methods to new classes in the original jar files.
This indirection would remove the circular compile-time dependencies between
the package and the two jar files which it currently straddles. However, I have
misgivings about this approach because it so brazenly tries to confuse and
subvert the compiler's good judgment.
S2) Combine the two original jar files into one, monster jar file. I don't like
this approach either. That is because it bloats up application footprints. It
frustrates one of jigsaw's primary goals, viz., the goal of reducing the size
of compiled applications.
Perhaps some other solution will occur to you. Maybe I am worrying about
non-problems. Maybe some variation of the following approach would work:
A1) S1 without the extra labor. That is, don't re-plumb the classes. Instead,
just move them into the slim, new jar file unchanged. Maybe there is some way
to tell the linker to not drag in one of the dependent jar files when packaging
a complete application. For instance, this might be a use for aggregator
modules. There could be an aggregator module for use by applications which run
client-side vs. an aggregator module for use by applications which run
server-side.
Thanks for any advice you can give.
-Rick
> 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, 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)
