On Sat, 7 Dec 2024 07:29:05 GMT, liyazzi wrote:
> For two cases:
>
> 1. When the ImageReaderFactory was loaded by local jdk,that means the
> ImageReaderFactory was loaded by boot class loader,then init the `Path
> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemPro
On Thu, 19 Dec 2024 11:46:36 GMT, Alan Bateman wrote:
> I'm happy with the current changes in the PR. The copyright header date in
> ImageReaderFactory can be updated to 2024, and the import of Disabled can be
> removed from the SetDefaultProvider test.
>
> To your question about tests then it
On Thu, 19 Dec 2024 12:33:50 GMT, Alan Bateman wrote:
>> liyazzi has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update the date of 'ImageReaderFactory'
>> - Update the date of '
ue to it is in jdk internal.
> 2. When loaded by a target jdk, such as jdk8 runtime, then use the Java 8
> compatible APIs: `FileSystems.getDefault()` to init the `BOOT_MODULES_JIMAGE`
> field.
> Then we can avoid the circular dependencies in class loading caused by
> loading the de
On Thu, 19 Dec 2024 09:23:27 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.ni
ue to it is in jdk internal.
> 2. When loaded by a target jdk, such as jdk8 runtime, then use the Java 8
> compatible APIs: `FileSystems.getDefault()` to init the `BOOT_MODULES_JIMAGE`
> field.
> Then we can avoid the circular dependencies in class loading caused by
> loading the de
On Sun, 15 Dec 2024 09:46:07 GMT, Alan Bateman wrote:
> The bigger question is whether specification of FileSystems.getDefault should
> be revised to specify how it should work when the default file system
> provider is deployed as a module (which would cover the case where there the
> provide
On Wed, 11 Dec 2024 09:48:36 GMT, liyazzi wrote:
> In [macos-x64 / test (jdk/tier1 part
> 1)](https://github.com/liyazzi/jdk/actions/runs/12252749523/job/34182811710),`jdk/internal/vm/Continuation/Fuzz.java#preserve-fp]:
> Fuzz tests for jdk.internal.vm.Continuation` failed, Does
ue to it is in jdk internal.
> 2. When loaded by a target jdk, such as jdk8 runtime, then use the Java 8
> compatible APIs: `FileSystems.getDefault()` to init the `BOOT_MODULES_JIMAGE`
> field.
> Then we can avoid the circular dependencies in class loading caused by
> loading the de
On Tue, 10 Dec 2024 09:07:32 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.ni
ue to it is in jdk internal.
> 2. When loaded by a target jdk, such as jdk8 runtime, then use the Java 8
> compatible APIs: `FileSystems.getDefault()` to init the `BOOT_MODULES_JIMAGE`
> field.
> Then we can avoid the circular dependencies in class loading caused by
> loading the de
ue to it is in jdk internal.
> 2. When loaded by a target jdk, such as jdk8 runtime, then use the Java 8
> compatible APIs: `FileSystems.getDefault()` to init the `BOOT_MODULES_JIMAGE`
> field.
> Then we can avoid the circular dependencies in class loading caused by
> loading the de
ue to it is in jdk internal.
> 2. When loaded by a target jdk, such as jdk8 runtime, then use the Java 8
> compatible APIs: `FileSystems.getDefault()` to init the `BOOT_MODULES_JIMAGE`
> field.
> Then we can avoid the circular dependencies in class loading caused by
> loading the de
ue to it is in jdk internal.
> 2. When loaded by a target jdk, such as jdk8 runtime, then use the Java 8
> compatible APIs: `FileSystems.getDefault()` to init the `BOOT_MODULES_JIMAGE`
> field.
> Then we can avoid the circular dependencies in class loading caused by
> loading the de
On Sat, 7 Dec 2024 13:46:18 GMT, liyazzi wrote:
> All of the `test (hs/tier1 compiler not-xcomp)` failed. Does it matter?
@AlanBateman Is the failure of `test (hs/tier1 compiler not-xcomp)` related to
this issue? I should correct the corresponding test, right?
-
PR Comment: ht
On Sat, 7 Dec 2024 09:16:58 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.De
On Sat, 7 Dec 2024 09:10:14 GMT, Alan Bateman wrote:
> This is the 3rd PR created for this issue, would it be possible to say if you
> are working with jyxzwd on this issue?
Yeah, There were something wrong with his OCA, so I re-issued this PR
-
PR Comment: https://git.openjdk.org
ue to it is in jdk internal.
> 2. When loaded by a target jdk, such as jdk8 runtime, then use the Java 8
> compatible APIs: `FileSystems.getDefault()` to init the `BOOT_MODULES_JIMAGE`
> field.
> Then we can avoid the circular dependencies in class loading caused by
> loading the de
For two cases:
1. When the ImageReaderFactory was loaded by local jdk,that means the
ImageReaderFactory was loaded by boot class loader,then init the `Path
BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which is
obtained through reflection,due to it is in jdk internal.
2.
19 matches
Mail list logo
