Re-export (was: Updated JSR-277 specification (04/19/2007))
cierniak at google.com
Mon May 14 22:13:45 PDT 2007
On 5/14/07, Stanley M. Ho <Stanley.Ho at sun.com> wrote:
> Supposes module A imports modules B and C, and module B also imports and
> re-exports module C. Using the expanded-export-list approach would cause
> module A fail to initialize - the shallow validation could detect
> duplicate types from the imported modules B and C but would be unable to
> determine if the duplicate types were originated from the same module C.
> Under the current algorithms in the updated specification, module A
> would be initialized successfully, which is the correct behavior.
Well, this is true if we don't mark such types as "re-exported". What
if C's exports that are added to B's are marked with a bit that means
"re-exported"? Your example would still work and we would get better
error diagnostic. For instance if your example was expanded to make B
import and re-export C and D. If a signature of a method of one of
B's exported types contained a type from C and the version of C that
was wired to B at runtime lacked that type, we would have no idea why
B failed to validate. Was it malformed to begin with? Or was it that
one of its imports changed?
If no one else thinks that this might be useful, I will not really
press for such a feature. As I said in my previous email, I don't
really have a strong opinion. I was asking to get a clarification
what your intent was.
More information about the jsr277-eg-observer