[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