Jak wyodrębnić plik jre-9/lib/modules?

Question

W katalogu JRE-9/lib (przynajmniej w systemie Windows) znajduje się nowy plik o nazwie modules, którego rozmiar wynosi około 107 MB. Czy można wyodrębnić ten plik, czy może wymienić w nim moduły java?

widzę, że nowe narzędzie o nazwie jmod jest dostępny na jdk-9/bin/jmod.exe, ale to jest do czytania .jmod pliki, które znajduje się na jdk-9/jmods i nie można odczytać pliku modules.

Answer 1

Plik modules to plik kontenera. Jest wewnętrzna dla JDK, a format nie jest udokumentowany (może się zmienić w dowolnym momencie). Do celów rozwiązywania problemów można użyć narzędzia jimage w katalogu bin, aby wyświetlić listę lub wyodrębnić zawartość.

Answer 2

Można wymienić moduły poprzez java --list-modules

Answer 3

Plik modules ma być pojedynczy plik (nie przeznaczone do ekstrakcji wszędzie), która zawiera binarną reprezentację wszystkich modułów obecnych w JDK w formacie undocument który może ulec zmianie. Możesz wyświetlić listę modułów, które zawiera: java --list-modules.

Początkowo plik modules będzie zawierać każdy moduł i zasadniczo podwoić bok JDK na własną rękę, ale po „minify” JDK przy użyciu narzędzia jlink plik modules staną się mniejsze (przy założeniu, że program zawiera podzbiór modułów dostarczanych z JDK). Więcej informacji na temat jlink można znaleźć tutaj: http://openjdk.java.net/jeps/282

Answer 4

Zasoby środowiska wykonawczego są obsługiwane w sposób kompatybilny wstecz. Na przykład. kiedy zrobiłeś

URL url = Object.class.getResource("Object.class"); 
System.out.println(url); 

w przeszłości, zwykle coś podobnego

jar:file:/path-to-jre/lib/rt.jar!/java/lang/Object.class 

bieganie to samo pod Java 9 dadzą Ci

jrt:/java.base/java/lang/Object.class 

zamiast. W obu przypadkach można otworzyć na nim FileSystem, aby sprawdzić inne dostępne zasoby (od Javy 7). Choć ZipFileSystem musiał zostać stworzony przez FileSystems.newFileSystem pierwszy system plików Java 9.x jest nawet już otwarta do użytku:

private static void readMyOwnJRE() throws IOException { 
    try { 
     Path p = Paths.get(URI.create("jrt:/modules")); 
     System.out.println("My own JRE's modules:"); 
     Files.list(p).forEach(System.out::println); 
     System.out.println(); 
    } catch(FileSystemNotFoundException ex) { 
     System.out.println("Could not read my modules (perhaps not Java 9?)."); 
    } 
} 

Jeśli działa pod inną JRE niż ten, który chcesz sprawdzić, trzeba załadować wdrożenie systemu odpowiedni plik ręcznie pierwszy, ale ta otwiera możliwość wglądu do instalacji Java 9 nawet z Java 8 JRE:

public static void readOtherJRE(Path pathToJRE) throws IOException { 
    Path p = pathToJRE.resolve("lib").resolve("jrt-fs.jar"); 
    if(Files.exists(p)) { 
     try(URLClassLoader loader = new URLClassLoader(new URL[]{ p.toUri().toURL() }); 
      FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), 
                 Collections.emptyMap(), 
                 loader)) { 
      System.out.println("Modules of "+pathToJRE); 
      Files.list(fs.getPath("/modules")).forEach(System.out::println); 
      System.out.println(); 
     } 
    } 
} 

---

Gdy masz system plików (lub Path do niego), y możesz użyć wszystkich standardowych funkcji, np. Files do sprawdzenia lub wyodrębnienia/skopiowania danych, chociaż właściwym terminem byłoby "przechowywać równoważny plik klasy" w innym systemie plików, ponieważ reprezentacja obrazu środowiska wykonawczego wcale nie musi być plikiem klasy.

Answer 5

Możesz użyć pliku jdk.internal.jimage.ImageReader, aby przeczytać ten plik.