FULL PRODUCT VERSION :
"Consumer" JRE
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing)

"Producer" JDK
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b20)
Java HotSpot(TM) Client VM (build 1.9.0-ea-b20, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
According to the latest security recommendations from Oracle, I have been trying to timestamp my jar files at signature time. If I sign with JDK 9, JRE 7 complains "Found unsigned entry in resource".

Complete compatibility matrix as far as I can see:
Sign | Run | Works?
With | With | Works?
  7 7 Y
  8 7 Y
  9 7 N
  7 8 Y
  8 8 Y
  9 8 N
  7 9 Y
  8 9 Y
  9 9 Y
  
It looks like this is a bug in the signature process rather than the verification process, but it may be a problem with the verification instead?

REGRESSION. Last worked in version 8u20

ADDITIONAL REGRESSION INFORMATION:
"Consumer" JRE
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) Client VM (build 24.60-b09, mixed mode, sharing)

"Producer" JDK
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b20)
Java HotSpot(TM) Client VM (build 1.9.0-ea-b20, mixed mode, sharing)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a small webstart application
2. Obtain a code signature certificate
3. Sign with JDK 9
C:\>"C:\Program Files (x86)\Java\jdk1.9.0\bin\jarsigner.exe" -storepass password -tsa https://timestamp.geotrust.com example.jar.9b20 test
4. Launch the webstart application from a machine without JDK 9 installed

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application should launch and run normally
ACTUAL -
The application doesn't run, claiming that the JAR file contains unsigned entries

ERROR MESSAGES/STACK TRACES THAT OCCUR :
com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://webstart.example.com/test.jar.9b20
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Don't use timestamping or timestamp with JDK 8 or earlier