On 27/08/2019 18:09, Stephan Herrmann wrote:
:
For the problem at hand I see two possible solutions:
- the "hack" of forging the ModulePackages attribute
- rename the folder to change it from encapsulated (a) to legacy (c).
Both options have some kind of negative smell, so let me ask: which
so
Much clearer, still a few comments.
On 27.08.19 09:05, Alan Bateman wrote:
- What should happen when (2) declares a set of packages that differs from
what scanning would result in? Can (2), e.g., be used to hide a package?
The ModulePackages attribute would win in that case, at least in the JDK
On 26/08/2019 22:37, Stephan Herrmann wrote:
:
If the above list is correct (complete?), some questions remain:
- What should happen when (2) declares a set of packages that differs
from what scanning would result in? Can (2), e.g., be used to hide a
package?
The ModulePackages attribute woul
Thanks Alan,
This looks like quite a party of stakeholders discussing what is or is not a
package. Let me check if I get it right:
(1) JLS requires a package declaration in a compilation unit for a package to
exist.
(2) a class file attribute in module-info.class may declare the set of packa
On 24/08/2019 21:11, Stephan Herrmann wrote:
Hi,
back then when working on our compiler I didn't pay much attention to
non-Java resources, as JLS doesn't make any mention of them.
Recently, however, we found that plain text files in a modular jar can
well cause the VM to refuse starting,
I
Hi,
back then when working on our compiler I didn't pay much attention to non-Java
resources, as JLS doesn't make any mention of them.
Recently, however, we found that plain text files in a modular jar can well
cause the VM to refuse starting, complaining:
java.lang.LayerInstantiationExcept
