Jak wyświetlić listę plików w pliku JAR?

Kod, który działa zarówno dla IDE i .pliki 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());
        }
    }
}

Odpowiedź Ericksona zadziałała idealnie:

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() ] );

A ja właśnie zmodyfikowałem metodę load z tego:

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

Do tego:

String  [] webimages = ...

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

Chciałbym rozszerzyć odpowiedź acheron55 , ponieważ jest to bardzo Nie bezpieczne rozwiązanie, z kilku powodów:

1. nie zamyka FileSystem obiektu.
2. nie sprawdza, czy obiekt FileSystem już istnieje.
3. to nie jest bezpieczne dla wątków.

Jest to nieco bezpieczniejsze rozwiązanie:

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());
    }
}   

Nie ma potrzeby synchronizacji nad nazwą pliku, można po prostu synchronizować na tym samym obiekcie za każdym razem (lub zrobić metodę synchronized), to tylko optymalizacja.

Powiedziałbym, że jest to nadal problematyczne rozwiązanie, ponieważ mogą istnieć inne części kodu, które używają interfejsu FileSystem nad tymi samymi plikami, i może to zakłócać ich działanie (nawet w pojedynczej aplikacji z wątkiem).
Ponadto, nie sprawdza nulls (na przykład na getClass().getResource().

Ten konkretny interfejs Java NIO jest trochę okropny, ponieważ wprowadza globalny / singleton Nie bezpieczny dla wątków zasób, a jego dokumentacja jest bardzo niejasna (wiele niewiadomych ze względu na implementacje specyficzne dla dostawcy). Wyniki mogą się różnić dla innych dostawców FileSystem (nie JAR). Może jest ku temu dobry powód; Nie wiem, nie badałem implementacji.

Więc myślę, że moim głównym problemem byłoby, jak poznać nazwę słoika, w którym mieszka moja główna klasa.

Zakładając, że twój projekt jest zapakowany w słoik (niekoniecznie prawda!), możesz użyć Classloadera.getResource() lub findResource () z nazwą klasy (po której następuje .class), aby uzyskać słoik, który zawiera daną klasę. Będziesz musiał przeanalizować nazwę jar z adresu URL, który zostanie zwrócony( nie taki trudny), który zostawię jako ćwiczenie dla czytelnika :-)

Pamiętaj, aby przetestować przypadek, w którym klasa nie jest częścią słoika.

Oto metoda, którą napisałem dla "run all JUnits under a package". Powinieneś być w stanie dostosować go do swoich potrzeb.

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));
            }
        }
    }
}

Edytuj: Ah, w takim razie, możesz też chcieć ten fragment (ten sam przypadek użycia:))

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);
    }
}

Plik jar jest tylko plikiem zip ze strukturyzowanym manifestem. Możesz otworzyć plik JAR za pomocą zwykłych narzędzi Java zip i skanować zawartość pliku w ten sposób, nadmuchiwać strumienie itp. Następnie użyj tego w wywołaniu getResourceAsStream, i powinno być wszystko ładne dory.

Edycja / po wyjaśnieniu

Zajęło mi minutę, aby zapamiętać wszystkie kawałki i kawałki i jestem pewien, że są czystsze sposoby, aby to zrobić, ale chciałem zobaczyć, że nie jestem szalony. W moim projekcie.jpg to plik w jakiejś części głównego pliku jar. Dostaję class loader klasy głównej (SomeClass jest punktem wejścia) i używam go do odkrywania obrazu.zasoby jpg. Potem trochę magii strumienia, aby wprowadzić ją do tego imageinputstream i wszystko jest w porządku.

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

Biorąc pod uwagę rzeczywisty plik JAR, możesz wyświetlić zawartość za pomocą JarFile.entries(). Musisz jednak znać lokalizację pliku JAR - nie możesz po prostu poprosić classloadera o listę wszystkiego, do czego mógłby się dostać.

Powinieneś być w stanie określić lokalizację pliku JAR na podstawie adresu URL zwróconego z ThisClassName.class.getResource("ThisClassName.class"), ale może to być trochę dziwne.

Jakiś czas temu zrobiłem funkcję, która pobiera klasę z wnętrza Jara:

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;
}

Oto przykład użycia Reflections library do rekurencyjnego skanowania classpath za pomocą wzorca nazw regex powiększonego o kilka atutówGuava do pobierania zawartości zasobów:

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);
}

To działa zarówno ze słoikami, jak i klasami wybuchowymi.

Istnieją dwa bardzo przydatne narzędzia, oba o nazwie JarScan:

1. Www.inetfeedback.com/jarscan

2. Jarscan.dev.java.net

Zobacz też to pytanie: JarScan, skanuje wszystkie pliki JAR we wszystkich podfolderach pod kątem określonej klasy

Przeportowałem odpowiedź acheron55 do Java 7 i zamknąłem obiekt FileSystem. Ten kod działa w IDE, w plikach jar i w jar wewnątrz wojny na Tomcat 7; ale zauważ, że nie działa w jar wewnątrz wojny na JBoss 7 (podaje FileSystemNotFoundException: Provider "vfs" not installed, Zobacz także ten post ). Ponadto, podobnie jak oryginalny kod, nie jest bezpieczny dla wątków, jak sugeruje errr . Z tych powodów zrezygnowałem z tego rozwiązania; jednak, jeśli możesz zaakceptować te kwestie, oto mój gotowy kod:

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;
                }
            });
        }
    }
}

Po prostu inny sposób wyświetlania / czytania plików z adresu URL jar i robi to rekurencyjnie dla zagnieżdżonych jarów

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 
    }
});