On 08/07/2016 13:46, Andrew Dinn wrote:
:
Jason addressed some of this in his post -- the nub (but definitely not
the total) of his points is in this paragraph
"This brings us to the problem with the proposal. The expectation AFAICT
appears to be that the user defining the enhanced code knows the
identity of the module enhancing it (e.g. exports dynamic
com.foo.app.model to jpa). The module is simply not in a position to
know that just “jpa” requires access. There might be more than one
version of jpa which needs to be selected dynamically, or jpa might be
broken into multiple modules itself. It’s effectively bleeding
container/framework implementation details into the user defined code."
I think the focus on qualified exports has been a bit of a distraction
in this thread. It might have been clearer if the thread has started out
without mentioning that possibility.
:
The major problem is the scale and difficulty of the legacy problem that
you are suggesting such a 'simple' fix for. There are already many, many
deployments which are not built the way you suggest they ought to be
rebuilt. It is very easy to say 'well sort them out' but that fails to
recognise the amount of work involved.
I don't recall anyone suggesting a simple fix. However, the so-called
"legacy problem" is a great topic and something that you might want to
spin off to its own thread. I'm not ignoring the rest of the mail, just
noting that a lot of appears to be reliable configuration.
-Alan.
