RFR: JDK-8172432,jar cleanup/update for module and mrm jar

Xueming Shen xueming.shen at oracle.com
Wed Jan 11 01:03:58 UTC 2017


On 1/9/17, 3:46 PM, Mandy Chung wrote:
>
>> On Jan 9, 2017, at 10:21 AM, Xueming Shen <xueming.shen at oracle.com 
>> <mailto:xueming.shen at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review the following proposed changes for jar tool
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8172432
>> webrev: http://cr.openjdk.java.net/~sherman/8172432/webrev
>> http://cr.openjdk.java.net/~sherman/8172432/webrev_top/
>>
>
> This is a good cleanup.  This makes it easier to add any further 
> validation such as JDK-8171830.
>
>
Hi Mandy,

I spent some time today for JDK-8171830.

http://cr.openjdk.java.net/~sherman/8172432/webrev2/src/jdk.jartool/share/classes/sun/tools/jar/Main.java.sdiff.html
--> Line#1851 checkModuleInfo()

http://cr.openjdk.java.net/~sherman/8172432/webrev2/test/tools/jar/modularJar/Basic.java.sdiff.html
--> Line#739

Only after I checked out the output bytes I realized that the current 
implementation
for "checkServices", in which it creates a ModuleDescriptor from bytes as

ModuleDescriptor md = 
ModuleDescriptor.read(ByteBuffer.wrap(moduleInfoBytes));

actually triggers the sanity check inside ModuleInfo.doRead(), which 
does validate if all
exported/open packages are contained in the "packages" attribute.

java.lang.module.InvalidModuleDescriptorException: Package jdk.test.bar missing from ModulePackages attribute
	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1078)
	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:318)
	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:141)
	at java.base/java.lang.module.ModuleDescriptor.read(ModuleDescriptor.java:2377)
	at jdk.jartool/sun.tools.jar.Main.checkModuleInfo(Main.java:1843)
	at jdk.jartool/sun.tools.jar.Main.run(Main.java:289)
	at jdk.jartool/sun.tools.jar.Main.main(Main.java:1651)


Just wanted to confirm with you that we actually don't need to do 
anything for 8171830,
other than throwing in a test case (or wrap the 
InvalidModuleDescriptorException into
a "jar" exception?

Thanks,
Sherman




More information about the core-libs-dev mailing list