Hi Alex,
(and redirecting the thread to net-dev)
It looks like a straight forward solution and perhaps the compatibility test
could be challenged on the basis of reliance on implementation behavior
rather than the spec.
But, more important I think is the behavior change of the fix itself and
that will require
careful review which we can't commit to immediately. We will try and get
back to you
about it in a week or so.
Thanks,
Michael.
On 14/03/2020 00:08, Alex Kashchenko wrote:
Hi,
Based on these maillist threads:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065076.html
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063643.html
I am looking for comments and suggestions, whether the following
change to JarURLConnection.getJarFile() behaviour may be acceptable:
If, during connect() call, jarFile itself was created successfully,
but access to (non-existent) jarEntry failed - return this jarFile to
caller instead of throwing exception.
bug: https://bugs.openjdk.java.net/browse/JDK-8132359
webrev: http://cr.openjdk.java.net/~akasko/jdk/8132359/webrev.00/
This change also allows to fix JDK-8232854 with the minimal change to
URLClassPath (included with the patch).
This change doesn't cause regression failures in java/net.
This change causes one compatibility failure, when getManifest()
doesn't throw expected IOException when URL points to non-existent
class inside JAR.
