[modules-dev] Review request for 6601899

Dave Bristor David.Bristor at Sun.COM
Tue Oct 30 10:51:46 PDT 2007


Stephen J. McConnell wrote:
> On Fri, 2007-10-26 at 17:45 -0700, Dave Bristor wrote:
>> Hi folks,
>>
>> This is to fix
>>
>> 6601899 (repo) URLRepository.find*() must not return modules for other than 
>> the appropriate platform/arch
>>
>> bugster: http://monaco.sfbay/detail.jsp?cr=6601899
>> webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6601899/
>>
>> The bulk of the work involves taking into account platform & arch when 
>> installing, finding, and listing modules.  There are several simplifications & 
>> cleanups.  The "interesting" changes are in
>>
>> LocalRepository
>> ModuleInfoXMLReader
>> URLRepository
>>
>> Changes in those (and to a lesser extent other files) are based on additions 
>> to RepositoryUtils.
>>
>> LocalRepositoryTest and URLRepositoryTest were updated to take into account 
>> platform/arch specifics.  There currently aren't any tests which look for the 
>> (IMHO unlikely) case of having specified platform but not arch or vice versa. 
> 
> According to javadoc that I've reading though recently (and supporting
> implementation code), the scenario you describe cannot exist.  Either
> both architecture and platform are specified as non-null OR both
> attributes are null.

If the javadoc says an invariant X should hold, then I hope that the code 
enforces X.  And then, it's reasonable to have a test for X, to see if it 
really does hold.

OTOH, upon your email's prodding, I looked at 
java.module.annotation.PlatformBinding and at RepositoryMetadata.xml: those 
APIs do indeed prevent having only one of platform/arch set.

Would you agree that no further test is necessary?  Thanks,
	Dave

> 
> Cheers, Steve. 
> 
> 
> 
> _______________________________________________
> modules-dev mailing list
> modules-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/modules-dev



More information about the modules-dev mailing list