On Sat, 9 Nov 2024 02:18:22 GMT, jyxzwd wrote:
> Use the built-in file system provider rather than the custom file system
> provider.
> Add "public static FileSystemProvider create" method in
> DefaultFileSystemProvider which is from java8API to be compatible against
> Use the built-in file system provider rather than the custom file system
> provider.
> Add "public static FileSystemProvider create" method in
> DefaultFileSystemProvider which is from java8API to be compatible against
> runtime.
jyxzwd has updated the pull request w
On Thu, 21 Nov 2024 14:08:33 GMT, Alan Bateman wrote:
> > Should I submit the modifications mentioned above to a commit, or should I
> > conduct further testing first?
>
> I think it would be good to add a test and add it to this PR with the updated
> patch.
ok,I will do this later.Thank you
On Wed, 20 Nov 2024 18:02:35 GMT, Alan Bateman wrote:
> > yeah,I tested it a few mins ago.It works well in the situation mentioned in
> > the issue and in the normal situation, also when a remote/target jdk is
> > set. But I have a doubt, when only using the local jdk, no
> > remote/targetjdk,
On Wed, 20 Nov 2024 14:11:51 GMT, Alan Bateman wrote:
> I don't think we should be doing this. Did you try the direction of checking
> the defining class loader that I outlined in the previous comment?
yeah,I tested it a few mins ago.It works well in the situation mentioned in the
issue and in
On Sun, 10 Nov 2024 17:04:12 GMT, Alan Bateman wrote:
>> If we load the custom DefaultFileSystemProvider by SystemClassLoader,then we
>> will step into the method
>> SystemModuleFinders$SystemModuleReader#findImageLocation again, and the var
>> imageReader will be null.But we can not define a
> Use the built-in file system provider rather than the custom file system
> provider.
> Add "public static FileSystemProvider create" method in
> DefaultFileSystemProvider which is from java8API to be compatible against
> runtime.
jyxzwd has updated the pull reque
On Sun, 10 Nov 2024 04:50:36 GMT, jyxzwd wrote:
>> The jrt file system provider supports both the current JDK and a
>> remote/target JDK. When the JDK is not the current JDK then it loads the jrt
>> file system provider from target's JDK jrt-fs.jar. To understand
On Sat, 9 Nov 2024 18:12:34 GMT, Alan Bateman wrote:
>> I was wondering, in JDK 17 or JDK 21, isn't classes in jrt-fs.jar already
>> included under the java.base module? This would mean that the classes in
>> jrt-fs.jar are actually already loaded by the bootstrapClassLoader, so a
>> custom cl
On Sat, 9 Nov 2024 08:57:17 GMT, Alan Bateman wrote:
>> Use the built-in file system provider rather than the custom file system
>> provider.
>> Add "public static FileSystemProvider create" method in
>> DefaultFileSystemProvider which is from java8API to be compatible against
>> runtime.
>
>
Use the built-in file system provider rather than the custom file system
provider.
Add "public static FileSystemProvider create" method in
DefaultFileSystemProvider which is from java8API to be compatible against
runtime.
-
Commit messages:
- 8331467: Fix JDK-8331467 ImageReaderFa
On Thu, 17 Oct 2024 03:37:38 GMT, jyxzwd wrote:
> Use the built-in file system provider rather than the custom file system
> provider.
> Add "public static FileSystemProvider create" method in
> DefaultFileSystemProvider which is from java8API to be compatible against
Use the built-in file system provider rather than the custom file system
provider.
Add "public static FileSystemProvider create" method in
DefaultFileSystemProvider which is from java8API to be compatible against
runtime.
-
Commit messages:
- 8331467: Fix JDK-8331467 ImageReaderFa
13 matches
Mail list logo
