¿Cómo enumerar los archivos dentro de un archivo JAR?

Tengo este código que lee todos los archivos de un directorio.

    File textFolder = new File("text_directory");

    File [] texFiles = textFolder.listFiles( new FileFilter() {
           public boolean accept( File file ) {
               return file.getName().endsWith(".txt");
           }
    });

Funciona muy bien. Llena la matriz con todos los archivos que terminan con ".txt" del directorio "text_directory".

¿Cómo puedo leer el contenido de un directorio de manera similar dentro de un archivo JAR?

Entonces, lo que realmente quiero hacer es enumerar todas las imágenes dentro de mi archivo JAR, para poder cargarlas con:

ImageIO.read(this.getClass().getResource("CompanyLogo.png"));

(Ese funciona porque el "CompanyLogo" está "codificado", pero la cantidad de imágenes dentro del archivo JAR podría ser de 10 a 200 de longitud variable).

EDITAR

Entonces supongo que mi principal problema sería: ¿Cómo saber el nombre del archivo JAR donde vive mi clase principal?

De acuerdo, podría leerlo usando java.util.Zip.

Mi estructura es así:

Ellos son como:

my.jar!/Main.class
my.jar!/Aux.class
my.jar!/Other.class
my.jar!/images/image01.png
my.jar!/images/image02a.png
my.jar!/images/imwge034.png
my.jar!/images/imagAe01q.png
my.jar!/META-INF/manifest 

Ahora mismo puedo cargar, por ejemplo, "images / image01.png" usando:

    ImageIO.read(this.getClass().getResource("images/image01.png));

Pero solo porque sé el nombre del archivo, para el resto tengo que cargarlos dinámicamente.

CodeSource src = MyClass.class.getProtectionDomain().getCodeSource();
if (src != null) {
  URL jar = src.getLocation();
  ZipInputStream zip = new ZipInputStream(jar.openStream());
  while(true) {
    ZipEntry e = zip.getNextEntry();
    if (e == null)
      break;
    String name = e.getName();
    if (name.startsWith("path/to/your/dir/")) {
      /* Do something with this entry. */
      ...
    }
  }
} 
else {
  /* Fail... */
}

Tenga en cuenta que en Java 7, puede crear un FileSystemarchivo desde el archivo JAR (zip) y luego usar los mecanismos de filtrado y desplazamiento del directorio de NIO para buscarlo. Esto facilitaría la escritura de código que maneje archivos JAR y directorios "explotados".

Código que funciona para archivos IDE y .jar:

import java.io.*;
import java.net.*;
import java.nio.file.*;
import java.util.*;
import java.util.stream.*;

public class ResourceWalker {
    public static void main(String[] args) throws URISyntaxException, IOException {
        URI uri = ResourceWalker.class.getResource("/resources").toURI();
        Path myPath;
        if (uri.getScheme().equals("jar")) {
            FileSystem fileSystem = FileSystems.newFileSystem(uri, Collections.<String, Object>emptyMap());
            myPath = fileSystem.getPath("/resources");
        } else {
            myPath = Paths.get(uri);
        }
        Stream<Path> walk = Files.walk(myPath, 1);
        for (Iterator<Path> it = walk.iterator(); it.hasNext();){
            System.out.println(it.next());
        }
    }
}

La respuesta de Erickson funcionó perfectamente:

Aquí está el código de trabajo.

CodeSource src = MyClass.class.getProtectionDomain().getCodeSource();
List<String> list = new ArrayList<String>();

if( src != null ) {
    URL jar = src.getLocation();
    ZipInputStream zip = new ZipInputStream( jar.openStream());
    ZipEntry ze = null;

    while( ( ze = zip.getNextEntry() ) != null ) {
        String entryName = ze.getName();
        if( entryName.startsWith("images") &&  entryName.endsWith(".png") ) {
            list.add( entryName  );
        }
    }

 }
 webimages = list.toArray( new String[ list.size() ] );

Y acabo de modificar mi método de carga a partir de esto:

File[] webimages = ... 
BufferedImage image = ImageIO.read(this.getClass().getResource(webimages[nextIndex].getName() ));

A esto:

String  [] webimages = ...

BufferedImage image = ImageIO.read(this.getClass().getResource(webimages[nextIndex]));

Me gustaría ampliar la respuesta de acheron55 , ya que es una solución muy poco segura, por varias razones:

1. No cierra el FileSystemobjeto.
2. No comprueba si el FileSystemobjeto ya existe.
3. No es seguro para subprocesos.

Esta es una solución algo más segura:

private static ConcurrentMap<String, Object> locks = new ConcurrentHashMap<>();

public void walk(String path) throws Exception {

    URI uri = getClass().getResource(path).toURI();
    if ("jar".equals(uri.getScheme()) {
        safeWalkJar(path, uri);
    } else {
        Files.walk(Paths.get(path));
    }
}

private void safeWalkJar(String path, URI uri) throws Exception {

    synchronized (getLock(uri)) {    
        // this'll close the FileSystem object at the end
        try (FileSystem fs = getFileSystem(uri)) {
            Files.walk(fs.getPath(path));
        }
    }
}

private Object getLock(URI uri) {

    String fileName = parseFileName(uri);  
    locks.computeIfAbsent(fileName, s -> new Object());
    return locks.get(fileName);
}

private String parseFileName(URI uri) {

    String schemeSpecificPart = uri.getSchemeSpecificPart();
    return schemeSpecificPart.substring(0, schemeSpecificPart.indexOf("!"));
}

private FileSystem getFileSystem(URI uri) throws IOException {

    try {
        return FileSystems.getFileSystem(uri);
    } catch (FileSystemNotFoundException e) {
        return FileSystems.newFileSystem(uri, Collections.<String, String>emptyMap());
    }
}   

No hay ninguna necesidad real de sincronizar sobre el nombre del archivo; uno podría simplemente sincronizar en el mismo objeto cada vez (o hacer el método synchronized), es puramente una optimización.

Diría que esta sigue siendo una solución problemática, ya que podría haber otras partes en el código que usen la FileSysteminterfaz sobre los mismos archivos y podría interferir con ellos (incluso en una aplicación de un solo subproceso).
Además, no busca nulls (por ejemplo, on getClass().getResource().

Esta interfaz Java NIO en particular es algo horrible, ya que introduce un recurso global / singleton no seguro para subprocesos, y su documentación es extremadamente vaga (muchas incógnitas debido a implementaciones específicas del proveedor). Los resultados pueden variar para otros FileSystemproveedores (no para JAR). Quizás haya una buena razón para que sea así; No lo sé, no he investigado las implementaciones.

Así que supongo que mi principal problema sería cómo saber el nombre del frasco donde vive mi clase principal.

Suponiendo que su proyecto está empaquetado en un Jar (¡no necesariamente cierto!), Puede usar ClassLoader.getResource () o findResource () con el nombre de la clase (seguido de .class) para obtener el jar que contiene una clase determinada. Tendrá que analizar el nombre del jar de la URL que se devuelve (no es tan difícil), que dejaré como ejercicio para el lector :-)

Asegúrese de probar el caso en el que la clase no sea parte de un frasco.

Me he portado respuesta de acheron55 a Java 7 y cerré el FileSystemobjeto. Este código funciona en IDE, en archivos jar y en un jar dentro de una guerra en Tomcat 7; pero tenga en cuenta que no funciona en un frasco dentro de una guerra en JBoss 7 (da FileSystemNotFoundException: Provider "vfs" not installed, vea también esta publicación ). Además, como el código original, no es seguro para subprocesos, como sugiere errr . Por estas razones he abandonado esta solución; sin embargo, si puede aceptar estos problemas, aquí está mi código listo para usar:

import java.io.IOException;
import java.net.*;
import java.nio.file.*;
import java.nio.file.attribute.BasicFileAttributes;
import java.util.Collections;

public class ResourceWalker {

    public static void main(String[] args) throws URISyntaxException, IOException {
        URI uri = ResourceWalker.class.getResource("/resources").toURI();
        System.out.println("Starting from: " + uri);
        try (FileSystem fileSystem = (uri.getScheme().equals("jar") ? FileSystems.newFileSystem(uri, Collections.<String, Object>emptyMap()) : null)) {
            Path myPath = Paths.get(uri);
            Files.walkFileTree(myPath, new SimpleFileVisitor<Path>() { 
                @Override
                public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
                    System.out.println(file);
                    return FileVisitResult.CONTINUE;
                }
            });
        }
    }
}

Aquí hay un método que escribí para "ejecutar todos los JUnits en un paquete". Debería poder adaptarlo a sus necesidades.

private static void findClassesInJar(List<String> classFiles, String path) throws IOException {
    final String[] parts = path.split("\\Q.jar\\\\E");
    if (parts.length == 2) {
        String jarFilename = parts[0] + ".jar";
        String relativePath = parts[1].replace(File.separatorChar, '/');
        JarFile jarFile = new JarFile(jarFilename);
        final Enumeration<JarEntry> entries = jarFile.entries();
        while (entries.hasMoreElements()) {
            final JarEntry entry = entries.nextElement();
            final String entryName = entry.getName();
            if (entryName.startsWith(relativePath)) {
                classFiles.add(entryName.replace('/', File.separatorChar));
            }
        }
    }
}

Editar: Ah, en ese caso, es posible que también desee este fragmento (mismo caso de uso :))

private static File findClassesDir(Class<?> clazz) {
    try {
        String path = clazz.getProtectionDomain().getCodeSource().getLocation().getFile();
        final String codeSourcePath = URLDecoder.decode(path, "UTF-8");
        final String thisClassPath = new File(codeSourcePath, clazz.getPackage().getName().repalce('.', File.separatorChar));
    } catch (UnsupportedEncodingException e) {
        throw new AssertionError("impossible", e);
    }
}

Aquí hay un ejemplo del uso de la biblioteca Reflections para escanear de forma recursiva classpath por patrón de nombre de expresión regular aumentado con un par de ventajas de Guava para recuperar el contenido de los recursos:

Reflections reflections = new Reflections("com.example.package", new ResourcesScanner());
Set<String> paths = reflections.getResources(Pattern.compile(".*\\.template$"));

Map<String, String> templates = new LinkedHashMap<>();
for (String path : paths) {
    log.info("Found " + path);
    String templateName = Files.getNameWithoutExtension(path);
    URL resource = getClass().getClassLoader().getResource(path);
    String text = Resources.toString(resource, StandardCharsets.UTF_8);
    templates.put(templateName, text);
}

Esto funciona tanto con jarras como con clases explosionadas.

Un archivo jar es solo un archivo zip con un manifiesto estructurado. Puede abrir el archivo jar con las herramientas habituales de java zip y escanear el contenido del archivo de esa manera, inflar secuencias, etc. Luego úselo en una llamada getResourceAsStream, y debería ser todo perfecto.

EDITAR / después de la aclaración

Me tomó un minuto recordar todos los detalles y estoy seguro de que hay formas más limpias de hacerlo, pero quería ver que no estaba loco. En mi proyecto, image.jpg es un archivo en alguna parte del archivo jar principal. Obtengo el cargador de clases de la clase principal (SomeClass es el punto de entrada) y lo uso para descubrir el recurso image.jpg. Luego, algo de magia de flujo para meterlo en este elemento ImageInputStream y todo está bien.

InputStream inputStream = SomeClass.class.getClassLoader().getResourceAsStream("image.jpg");
JPEGImageReaderSpi imageReaderSpi = new JPEGImageReaderSpi();
ImageReader ir = imageReaderSpi.createReaderInstance();
ImageInputStream iis = new MemoryCacheImageInputStream(inputStream);
ir.setInput(iis);
....
ir.read(0); //will hand us a buffered image

Dado un archivo JAR real, puede enumerar el contenido usando JarFile.entries(). Sin embargo, necesitará saber la ubicación del archivo JAR; no puede simplemente pedirle al cargador de clases que enumere todo lo que puede encontrar.

Debería poder calcular la ubicación del archivo JAR en función de la URL devuelta ThisClassName.class.getResource("ThisClassName.class"), pero puede ser un poco complicado.

Hace algún tiempo hice una función que obtiene clases desde dentro de JAR:

public static Class[] getClasses(String packageName) 
throws ClassNotFoundException{
    ArrayList<Class> classes = new ArrayList<Class> ();

    packageName = packageName.replaceAll("\\." , "/");
    File f = new File(jarName);
    if(f.exists()){
        try{
            JarInputStream jarFile = new JarInputStream(
                    new FileInputStream (jarName));
            JarEntry jarEntry;

            while(true) {
                jarEntry=jarFile.getNextJarEntry ();
                if(jarEntry == null){
                    break;
                }
                if((jarEntry.getName ().startsWith (packageName)) &&
                        (jarEntry.getName ().endsWith (".class")) ) {
                    classes.add(Class.forName(jarEntry.getName().
                            replaceAll("/", "\\.").
                            substring(0, jarEntry.getName().length() - 6)));
                }
            }
        }
        catch( Exception e){
            e.printStackTrace ();
        }
        Class[] classesA = new Class[classes.size()];
        classes.toArray(classesA);
        return classesA;
    }else
        return null;
}

public static ArrayList<String> listItems(String path) throws Exception{
    InputStream in = ClassLoader.getSystemClassLoader().getResourceAsStream(path);
    byte[] b = new byte[in.available()];
    in.read(b);
    String data = new String(b);
    String[] s = data.split("\n");
    List<String> a = Arrays.asList(s);
    ArrayList<String> m = new ArrayList<>(a);
    return m;
}

Hay dos utilidades muy útiles, ambas llamadas JarScan:

1. www.inetfeedback.com/jarscan

2. jarscan.dev.java.net

Vea también esta pregunta: JarScan, escanee todos los archivos JAR en todas las subcarpetas para una clase específica

El mecanismo más robusto para enumerar todos los recursos en la ruta de clases es actualmente usar este patrón con ClassGraph , porque maneja la más amplia gama posible de mecanismos de especificación de rutas de clases , incluido el nuevo sistema de módulos JPMS. (Soy el autor de ClassGraph.)

¿Cómo saber el nombre del archivo JAR donde vive mi clase principal?

URI mainClasspathElementURI;
try (ScanResult scanResult = new ClassGraph().whitelistPackages("x.y.z")
        .enableClassInfo().scan()) {
    mainClasspathElementURI =
            scanResult.getClassInfo("x.y.z.MainClass").getClasspathElementURI();
}

¿Cómo puedo leer el contenido de un directorio de manera similar dentro de un archivo JAR?

List<String> classpathElementResourcePaths;
try (ScanResult scanResult = new ClassGraph().overrideClasspath(mainClasspathElementURI)
        .scan()) {
    classpathElementResourcePaths = scanResult.getAllResources().getPaths();
}

También hay muchas otras formas de gestionar los recursos .

Solo una forma diferente de enumerar / leer archivos de una URL de jar y lo hace de forma recursiva para jarras anidadas

https://gist.github.com/trung/2cd90faab7f75b3bcbaa

URL urlResource = Thead.currentThread().getContextClassLoader().getResource("foo");
JarReader.read(urlResource, new InputStreamCallback() {
    @Override
    public void onFile(String name, InputStream is) throws IOException {
        // got file name and content stream 
    }
});

Uno más para el camino:

import java.io.IOException;
import java.net.URISyntaxException;
import java.nio.file.*;
import java.util.ArrayList;
import java.util.List;

import static java.nio.file.FileSystems.newFileSystem;
import static java.util.Collections.emptyMap;

public class ResourceWalker {
  private static final PathMatcher FILE_MATCHER =
      FileSystems.getDefault().getPathMatcher( "glob:**.ttf" );

  public static List<Path> walk( final String directory )
      throws URISyntaxException, IOException {
    final List<Path> filenames = new ArrayList<>();
    final var resource = ResourceWalker.class.getResource( directory );

    if( resource != null ) {
      final var uri = resource.toURI();
      final var path = uri.getScheme().equals( "jar" )
          ? newFileSystem( uri, emptyMap() ).getPath( directory )
          : Paths.get( uri );
      final var walk = Files.walk( path, 10 );

      for( final var it = walk.iterator(); it.hasNext(); ) {
        final Path p = it.next();
        if( FILE_MATCHER.matches( p ) ) {
          filenames.add( p );
        }
      }
    }

    return filenames;
  }
}

Esto es un poco más flexible para hacer coincidir nombres de archivos específicos porque usa comodines globbing.

Un estilo más funcional:

import java.io.IOException;
import java.net.URISyntaxException;
import java.nio.file.*;
import java.util.function.Consumer;

import static java.nio.file.FileSystems.newFileSystem;
import static java.util.Collections.emptyMap;

/**
 * Responsible for finding file resources.
 */
public class ResourceWalker {
  private static final PathMatcher FILE_MATCHER =
      FileSystems.getDefault().getPathMatcher( "glob:**.ttf" );

  public static void walk( final String dirName, final Consumer<Path> f )
      throws URISyntaxException, IOException {
    final var resource = ResourceWalker.class.getResource( dirName );

    if( resource != null ) {
      final var uri = resource.toURI();
      final var path = uri.getScheme().equals( "jar" )
          ? newFileSystem( uri, emptyMap() ).getPath( dirName )
          : Paths.get( uri );
      final var walk = Files.walk( path, 10 );

      for( final var it = walk.iterator(); it.hasNext(); ) {
        final Path p = it.next();
        if( FILE_MATCHER.matches( p ) ) {
          f.accept( p );
        }
      }
    }
  }
}