jRT | jRT measures the response time | HTTP library

Refer to javadoc for method list (in class java.nio.file.Files). Here is the relevant part.

API Note:
This method must be used within a try-with-resources statement or similar control structure to ensure that the stream's open directory is closed promptly after the stream's operations have completed.

In other words you need to close the Stream returned by your modules method.

I think what you want is impossible. To wit:

• Up to JDK8, you can rely on e.g. Paths.get(pathToJdk8Home, "jre", "lib", "rt.jar") to exist, which you can then turn into a URL (you're looking for jar:file:/that/path), and you can then toss that URL at FileSystems.newFileSystem), see this documentation for more.
• But from JDK9 and up, the core java API is loaded in jmod files, and jmod files have an unspecified format by design - right now jmods are just zips, but unlike jars you explicitly get no guarantees that they will remain zip formatted, and there is no jmod URL scheme and no JmodFileSystemProvider. It is, in effect, impossible to read a jmod file in a way that is future compatible. Unfortunately the OpenJDK project has been on a murderous spree turning a ton of useful things, such as 'read a jmod', into implementation details. Bit user-hostile - just be aware of that, and I'm trying to do some expectation management: Stuff like this is way, way harder, and a huge maintenance burden (as you're forced to dip into workarounds, hacks, and going beyond spec thus needing to check it still works for every point release). See also this SO answer.

The jrt scheme can only load data from jmods that are actually 'loaded' into the VM's mod base, which I gather is explicitly not what you want (in fact, I'm pretty sure you cannot load e.g. the JDK11 core jmods into a JDK14, as it already loaded its jmods, and you'd get a split package violation). The jrt:// URL scheme, per its spec, isn't base file system related. You specify a module name (or nothing, and you get all loaded modules as one file system). There is no place for you to list a JDK installation path or jmod file, so that can't help you either.

Thus, you have only two options:

• Accept that what you want cannot be done.
• Accept that you're going to have to write hackery (as in, go beyond things that specifications guarantee you), and you accept the large maintenance burden that comes with the territory.

The hackery would involve:

• Detect targeted JDK version or go on a hunting spree within the provided JDK installation directory (using e.g. Files.walk) to find a file named rt.jar. If it's there, load it up as ZipFileSystem and carry on. Modules 'do not exist', just turn any desired class into a path by replacing dots with slashes and appending .class (note that you'll need the binary name; e.g. package com.foo; class Outer { class Inner {}} means you want the name of Inner to be com.foo.Outer$Inner, so that you turn that into /com/foo/Outer$Inner.class).
• For JDK9 and up, hunt for a file at JDK_HOME/jmods/java.base.jmod, and throw that at ZipFileSystem. A given class is in subdir classes. So, you're looking for e.g. the entry classes/java/lang/Object.class within the zip (that jmod is the zip). However, festoon this code with comments stating that this is a total hack and there is zero guarantee that this will work in the future. I can tell you, however, that JDK16, at least, still has zip-based jmod files.
• Alternatively, given that you have a JDK installation path, you can use ProcessBuilder to exec List.of("JDK_HOME/bin/jmod" /* or jmod.exe, you'll have to check which one to call! */, "extract", "JDK_HOME/jmods/java.base.jmod"), but note that this will extract all of those files into the current working directory (you can set the cwd for the invoked process to be some dir you just created for the purpose of being filled with the files inside). Quite a big bazooka if all you wanted was the one file. (You can also use the --dir option instead). The advantage is that this will still work even if hypothetically JDK17 is using some different format; presumably JDK17 will still have both bin/jmod as well as jmods/java.base.jmod, and the bin/jmod of JDK17 should be able to unpack the jmod files in your JDK17 installation. Even if you are running all this from e.g. JDK16 which wouldn't be able to read them.

You don't necessarily need a File to create an InputStream. You can also use a Path together with Files::newInputStream :

I finally found the problem why I could not export files with p:dataExporter.

The web.xml file contained the context param javax.faces.PARTIAL_STATE_SAVING defined to false, so I commented out and I worked well!

The problem in web.xml

Eclipse uses Java in two ways. It runs Eclipse with Java, and it allows specifying Java Runtime Environments in Preferences. I rarely see any reason to set JAVA_HOME anymore, because I specify the paths to the JDKs I want to use. I always have multiple JDKs installed.

I specify which JDK to use to run Java by setting the "-vm" path in the "eclipse.ini" file (which points to the "bin" directory).

I specify which JDK to use to compile code by adding JREs in preferences, and sometimes editing the "Execution Environments" (subsection of "Java Runtime Environments") to point to specific JREs.

Your ZKM Script "open" statement specifies the {"*.class"} file filter. So you are filtering out ALL non-class files including your MANIFEST.MF. See https://www.zelix.com/klassmaster/docs/openStatement.html#filter.

A missing MANIFEST.MF will give you a "Invalid or corrupt jarfile" error. Note that your Zelix KlassMaster log file will contain messages like the following.

MESSAGE: Filtering out path 'obfuscateFatJar.jar!META-INF/MANIFEST.MF' because it does not match specified filter '{".class"}>' (D)*

You can work around this by not using a file filter (the safest option in this case) or by broadening your file filter to include other file types. E.g. {".class" || ".MF"}

The stack trace indicates that the issue is connected with the module loading rather than class loading, which explains why you don’t have the problem in JDK 8 that doesn’t have modules.

When you read the stack trace starting at the bottom, i.e.

The JRT namespace has been introduced with Java 9. You cannot access module data with Java 8 and below.

Allow me to quote the migration guide:

Class and resource files previously stored in lib/rt.jar, lib/tools.jar, lib/dt.jar and various other internal JAR files are stored in a more efficient format in implementation-specific files in the lib directory.