JDK-4408526 : jar -i omits service providers in index.list
  • Type: Bug
  • Component: tools
  • Sub-Component: jar
  • Affected Version: 1.3.0,6u6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2001-01-26
  • Updated: 2004-02-20
  • Resolved: 2004-02-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 b40Fixed
Related Reports
Duplicate :  
Description

Name: boT120536			Date: 01/25/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)


When a service provider is compiled into a jar, it must provide files in META-
INF/services. When a jar -i is run on that file, the META-INF/services
directory is not added to the directory list in META-INF/INDEX.LIST. When this
jar is used, the appropriate service providers are not found. When I don't
create the index in the jar, the service provider is found correctly.

  To reproduce the problem, you can try with any jar that includes a service
provider or use tritonus:
1. Download the latest CVS version of Tritonus, from
http://cvs.sourceforge.net/cvstarballs/tritonus-cvsroot.tar.gz.
2. build it (on linux) with "make compileinitial && make install"
3. cd test ; make MpegPlayer.java
4. java MpegPlayer "mp3file.mp3" should run fine, or at least NOT give the
error that the conversion is not supported.
5. jar -i ../dist/tritonus_core.jar
6. run again the MpegPlayer and the service provider isn't found, with an
UnsupportedAudioFileException.

Looking at the source code of jar/sun.misc.JarIndex:187:
                if (fileName.startsWith("META-INF")) {
                    continue;
                }
Everything inside META-INF is not included in INDEX.LIST. I think the service
provider files should be included in INDEX.LIST, as they are searched by the
classloader.
(Review ID: 111540) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b40 tiger-beta2
14-06-2004

WORK AROUND Name: boT120536 Date: 01/25/2001 I was able to fix the problem by manually adding a line "META-INF/services" in INDEX.LIST. ======================================================================
11-06-2004

PUBLIC COMMENTS -
10-06-2004

EVALUATION It would have been better to locate services somewhere other than META-INF, since they are indeed searched for by class loaders and are in no sense meta information at the level of jar file structure. Even that wouldn't have fully eliminated the problem, though, since there are numerous other offenders putting property files, other subdirectories, etc. into META-INF. There is no way to determine with complete accuracy which files in META-INF are part of the jar file's infrastructure and needn't be indexed. We could reasonably exclude top-level ".SF", ".DSA", and ".RSA" files (signature files and signature blocks). But in theory a new signature algorithm could be used with a new (and unpredictable) suffix. Given that, along with the fact that there's no harm done in having a superfluous "META-INF" entry in the index, it's probably not worth going to much effort trying to figure out what to exclude. Maybe just exclude the manifest file and the index file itself, and index anything else. ###@###.### 2003-02-25
25-02-2003