bryan.atsatt at oracle.com
Fri Jun 13 12:22:52 PDT 2008
Yeah, that was my original proposal (seems like years ago now :^), but
it means that you can never escape from your mistakes.
As a newbie, you create module X containing your code in package X. But
you have a dependency on package Y, so, following the traditional
keep-adding-to-the-classpath-till-it-works model, you throw in package
Y. But, argh, Y depends on Z, so you throw that in as well. Being a
newbie, you export everything to keep it simple.
Sometime later you realize it was a mistake to export Y and Z: your code
didn't actually depend on Z, nor did it expose Y. And the version of Y
that you want to use now is available in a shiny new module.
So you refactor to remove packages Y and Z and import Y instead.
But for compatibility, you are forced to also:
1. Import Z.
2. Re-export both Y and Z.
Ugly. Far worse though: it binds your importers both to the version of Y
that you depend on (but don't expose in your code), and the version of Z
that you don't depend on at all!
And all of this is a direct consequence of import-by-module. With
import-by-package, this issue just... vanishes.
Adrian Brock wrote:
> On Thu, 2008-06-12 at 17:13 -0700, Bryan Atsatt wrote:
>> Really, I just want to make it possible for a module developer to be in
>> a position to "know" that splitting one module into multiple modules
>> will not break existing importers. I'm quite open to other solutions, as
>> long as they are reasonable.
> But can't that also be achieved with the old module re-exporting the
> split out module for backwards compatibility purposes?
More information about the jsr277-eg-observer