Module loses its package after compilation when the package has nothing but a compilation unit with package declaration.

Alex Buckley alex.buckley at
Fri Oct 13 18:36:04 UTC 2017

On 10/12/2017 11:11 PM, Jayaprakash Arthanareeswaran wrote:
> Let's say module A has a package x.y.z which has which has the
> following:
> package x.y.z;
> Now module B requires module A. Module "B" also has, which
> imports "x.y.z.*".
> Compiling both A and B goes well. But things don't go well when I first
> compiler A and
> then B by having A in its module-path. I see the following:
>    error: package x.y.z does not exist

I assume module A exports package x.y.z. I also assume you're compiling 
A/ in the same invocation as, or with on 
the source path, so that the compiler knows of the package declaration 
and thus accepts the 'exports' directive which specifies the package.

Further assuming that you're working with an exploded directory tree, 
I'm not surprised by the error about x.y.z not existing. I would have 
expected an annotation processor running over the same exploded 
directory tree to not include x.y.z in A's getEnclosedElements().


> As you can clearly see, compilation is not consistent between the two
> modes. Also,
> APT considering a non-existing package doesn't make sense either.
> At the very least, the APT models should ignore the packages that don't
> exist anymore.
> Regards,
> Jay

More information about the compiler-dev mailing list