RFR: Additional tests for overlapping packages.

Alexandre (Shura) Iline alexandre.iline at oracle.com
Mon Oct 5 09:11:32 UTC 2015


On Oct 1, 2015, at 6:23 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 23/09/2015 15:45, Alexandre (Shura) Iline wrote:
>> Hi.
>> 
>> This change adds a few more cases to existing cases for overlapping packages:
>> http://cr.openjdk.java.net/~shurailine/webrev.overlapping.packages.2/
>> 
>> 
> 

While I am working on the rest, let me double check this one.

>      2. testOverlapUpgradePath assumes that the upgrade module path can be used as an alternative to the application module path. There are several discussion points around the upgrade module path but I don't expect it can be used to do anything other than upgrade modules that are on the system module path (or linked into the runtime image). So maybe this one should be dropped for now.
> 

If something is possible, it is bound to happen. Unless it is impossible to place a user code on the upgrade module path, somebody will.  For this, the test makes sense, even if it is assuming behavior beyond what is promised by the spec. 

Further on, if the behavior is currently undefined, then the more sense there is to keep the test, IMO. When the behavior changes, it is better to have the failing rather then to forget adding it later.

The only cases where it is better not to have this test are:
 - the test is invalid. For example there is no way to place any arbitrary code on the upgrade module path. 
 - the behavior is undefined so the error of package name overlap may or may not be reported.

Are you referring to any of these?

Shura


> 
> -Alan.



More information about the jigsaw-dev mailing list