On 1/9/17, 3:46 PM, Mandy Chung wrote:
On Jan 9, 2017, at 10:21 AM, Xueming Shen <xueming.s...@oracle.com
<mailto:xueming.s...@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
