Re-export (was: Updated JSR-277 specification (04/19/2007))

Michal Cierniak cierniak at
Mon May 14 22:13:45 PDT 2007

On 5/14/07, Stanley M. Ho <Stanley.Ho at> 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 mailing list