Take 2.
InvalidJarIndexException is thrown when an index is corrupt. It is a useful
piece of
information that the deployment of the jar files, on the class path, with
indices, are
"bad". It is really an Error. It indicates a serious problem with the
deployment that a
reasonable application should not try to handle.
Propose...
1) Update the Jar File Specification [1] ( 8152276 [2] ):
"Once the class loader finds a INDEX.LIST file in a particular jar file, it
always trusts
the information listed in it. If a mapping is found for a particular class,
but the class
loader fails to find it by following the link, ** an unspecified Error or
RuntimeException **
is thrown. When this occurs, the application developer should rerun the jar
tool on the
extension to get the right information into the index file."
2) Update the implementation to throw an ( unspecified ) Error. ( 8152190 [3]
)
No user code should every catch or try to handle this Error.
No user code should every have tried to catch or handle
InvalidJarIndexException
Webrev:
http://cr.openjdk.java.net/~chegar/8152190/00/
-Chris.
[1] http://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Overview
[2] https://bugs.openjdk.java.net/browse/JDK-8152276
[3] https://bugs.openjdk.java.net/browse/JDK-8152190
On 21 Mar 2016, at 17:42, Chris Hegarty <chris.hega...@oracle.com> wrote:
>
> On 21 Mar 2016, at 08:33, Alan Bateman <alan.bate...@oracle.com> wrote:
>
>> On 21/03/2016 05:53, Chris Hegarty wrote:
>>> sun.misc.JarIndex, and its accompanying InvalidJarIndexException, are not
>>> "Critical APIs", as defined by JEP 260, so they should be moved out of
>>> sun.misc and placed into a more appropriate package where they can
>>> be encapsulated.
>>>
>>> http://cr.openjdk.java.net/~chegar/8152190/00/
>>> https://bugs.openjdk.java.net/browse/JDK-8152190
>>>
>>> Since the Exception type is only ever statically referenced where it is
>>> thrown, I’ve moved it to a static nested class of JarIndex, so as to
>>> keep the namespace cleaner.
>>>
>> It probably should be located with URLClassPath but we should try to avoid
>> exporting jdk.internal.loader to other modules.
>
> Agreed.
>
>> I suspect the module-info.java in your webrev is based on a merge and
>> exporting this package to java.rmi seems dubious. Can we create a bug to get
>> this removed? It looks like RegistryImpl is using it out of convenience
>> rather than necessity.
>
> Correct. I filed 8152277 [1] to track this, and will have it out for review
> soon.
>
>> There's something fishy with InvalidJarIndexException. The JAR spec mentions
>> it but it's a JDK-specific exception. If it's thrown by the APIs in
>> java.util.jar then it should be specified in those APIs and the exception
>> needs to be java.util.jar.
>
> You may be right. I filed 8152276 [2] to track this issue.
>
> Once 8152277 is fixed, I’ll rethink the solution to this issue.
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8152277
> [2] https://bugs.openjdk.java.net/browse/JDK-8152276
>
