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

[Alex Buckley]

On 10/12/2017 11:11 PM, Jayaprakash Arthanareeswaran wrote:
> Let's say module A has a package x.y.z which has X.java which has the
> following:
> package x.y.z;
> Now module B requires module A. Module "B" also has A.java, 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/module-info.java in the same invocation as X.java, or with X.java 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().

Alex

> 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