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

[joe darcy]

Hello Jayaprakash,

Code review requests on this list concerning API changes to 
javax.lang.model as well as an explicit request in April 2017 for 
feedback on the complete set of API changes [1] associated with the 
maintenance review (MR) of JSR 269 didn't receive a response from those 
working on an independent implementation of the API before the MR 
concluded in May 2017 [2]. This lack of response held even after I 
explicitly invited feedback from an Eclipse jdt committer who was a 
fellow speaker at Devoxx US in March 2017.

If the goal is a more explicit specification, in my experience it would 
be more effective to send feedback requesting clarifications sometime 
before a release goes GA rather than literally the day after GA. [3]

To use language precisely, the apt tool and associated API shipped in 
JDK 5.0, were deprecated in JDK 7, and were removed from the platform in 
JDK 8. The com.sun.* apt API never was never updated in any way to 
support modules and is completely irrelevant to this discussion about 
the javax.lang.model.* API and standardized annotation processing, which 
has been part of javac since JDK 6, which shipped in 2006.

Cheers,

-Joe

[1] 
http://mail.openjdk.java.net/pipermail/compiler-dev/2017-April/010896.html

[2] https://jcp.org/en/jsr/results?id=5942

[3] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-September/013220.html


On 10/12/2017 11:11 PM, Jayaprakash Arthanareeswaran wrote:
> Hello experts,
> This question was originally raised via [1], admittedly late, but 
> didn't receive any
> response.I am re-posting it as advised by Alan Bateman.
> Towards the end of our development effort for Java 9, we found that 
> Javac and
> Eclipse compiler produced different results for 
> ModuleElement.getEnclosedElements()
> for a binary module under certain circumstances. Specifically, for a 
> binary module that
> exports a package that doesn't have any types (the sources had only a 
> compilation unit
> with a package declaration), Javac includes that package in the 
> enclosed element list,
> but Eclipse doesn't. I understand it is like this for consistency 
> sake, but does it make
> sense especially in light of what we see during the following example:
> 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
> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171013/c008b230/attachment.html>