Vitaliy
Vitaliy

Reputation: 8206

In Java 9, why are package collisions treated a bit differently in some cases?

I am experimenting with Java 9 and looking at the following scenarios:

Experiment 1

Running a main from 'C' gives a runtime error:

java.lang.RuntimeException: Package com.foo in both module B and module A

Experiment 2

Same as before but this time both export com.foo.

Result of executing main from C:

java.lang.module.ResolutionException: Modules B and A export package com.foo to module C

Experiment 3

Same as 2, but this time I declared package com.foo in module C.

Now I get a compilation error: Error:(4, 1) java: module C reads package com.foo from both A and B

Why aren't the first two cases not caught during compilation as well? Are there runtime properties I am not aware of that preclude resolution before executing the program?

Also, as far as error messages are concerned: in what way is the error message in experiment 2 better than the one given in experiment 1. It is not that if one of the modules does not export it that the end result will be any different. In other words, what was the consideration behind producing different error messages?

Upvotes: 7

Views: 544

Answers (1)

Alan Bateman
Alan Bateman

Reputation: 5459

Experiment #2 and #3 are split package issues and should be errors at both compile-time and run-time. For #2 I can't tell from your post why you don't see a compilation error when compiling C. You should see an error with text like "module C reads package com.foo from both A and B".

Experiment #1 is probably A, B, and C on the application module path where they cannot all live in the same name space (same class loader) due to the overlapping packages. The error message you see has been improved a bit in recent builds.

Note that the experiments here have been discussed in many threads on jigsaw-dev and that might be better place to bring up questions and experiences, at least while JDK 9 is still in development.

Upvotes: 7

Related Questions