RFR [9] 8152190: Move sun.misc.JarIndex and InvalidJarIndexException to an internal package

[Chris Hegarty]

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.hegarty at oracle.com> wrote:

> 
> On 21 Mar 2016, at 08:33, Alan Bateman <Alan.Bateman at 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
>