On Thu, 19 Sep 2024 22:12:28 GMT, Phil Race wrote:
> fix legal notices
Looks okay.
-
Marked as reviewed by bpb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21095#pullrequestreview-2316841147
On Sun, 8 Sep 2024 07:52:26 GMT, Shaojin Wen wrote:
> Similar to ObjectInputStream, use JLA.countPositives and
> JLA.inflateBytesToChars to speed up readUTF
Marked as reviewed by bpb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/20903#pullrequestreview-2316686796
On Wed, 18 Sep 2024 05:54:40 GMT, Jaikiran Pai wrote:
> The current state of this PR looks good to me. I'll review the CSR too.
Thanks, @jaikiran, for your assistance.
-
PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2358842957
On Wed, 28 Aug 2024 18:04:33 GMT, Brian Burkhalter wrote:
>> Add some verbiage stating that two buffered readers or input streams should
>> not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incr
On Thu, 5 Sep 2024 21:05:38 GMT, Brian Burkhalter wrote:
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
This pull request has now been integrated.
Changeset: 64e3a9ee
Author: Brian Burkhalte
On Sat, 14 Sep 2024 06:47:40 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8339574: Move symbolic link verbiage from class to constructor doc in
>> FIS/F
On Sat, 14 Sep 2024 07:03:05 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8339574: Move symbolic link verbiage from class to constructor doc in
>> FIS/F
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8339574: Add symbolic link verbi
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8339574: Address reviewer comme
On Tue, 10 Sep 2024 18:05:13 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/File.java line 1440:
>>
>>> 1438: * Renames the file denoted by this abstract pathname. If this
>>> pathname
>>> 1439: * denotes a symbolic lin
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8339574: Move symbolic link ve
On Fri, 13 Sep 2024 19:30:42 GMT, Magnus Ihse Bursie wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Clean up to address reviewer comments
>
> make/modules/java.base
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last
On Fri, 13 Sep 2024 19:30:42 GMT, Magnus Ihse Bursie wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Clean up to address reviewer comments
>
> make/modules/java.base
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last
On Fri, 13 Sep 2024 19:30:42 GMT, Magnus Ihse Bursie wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Clean up to address reviewer comments
>
> make/modules/java.base
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last
On Fri, 13 Sep 2024 16:45:22 GMT, Daniel Fuchs wrote:
>> I would have to check. The failure I observed occurred in both of these tests
>>
>> test/jdk/sun/net/www/protocol/http/NoNTLM.java
>> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java
>>
>> and nowhere else.
>
> I see. The test
On Fri, 13 Sep 2024 16:45:22 GMT, Daniel Fuchs wrote:
>> I would have to check. The failure I observed occurred in both of these tests
>>
>> test/jdk/sun/net/www/protocol/http/NoNTLM.java
>> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java
>>
>> and nowhere else.
>
> I see. The test
On Fri, 13 Sep 2024 16:45:22 GMT, Daniel Fuchs wrote:
>> I would have to check. The failure I observed occurred in both of these tests
>>
>> test/jdk/sun/net/www/protocol/http/NoNTLM.java
>> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java
>>
>> and nowhere else.
>
> I see. The test
On Fri, 13 Sep 2024 16:31:36 GMT, Daniel Fuchs wrote:
>>> [...] I'd expect that libnet would have been loaded before we reach
>>> NTLMAuthentication.
>>
>> In the (as of now) penultimate webrev 4f47d5a (Merge),
>> `WindowsNativeDispatcher` loaded it during boot phase 2. I think that
>> withou
On Fri, 13 Sep 2024 16:31:36 GMT, Daniel Fuchs wrote:
>>> [...] I'd expect that libnet would have been loaded before we reach
>>> NTLMAuthentication.
>>
>> In the (as of now) penultimate webrev 4f47d5a (Merge),
>> `WindowsNativeDispatcher` loaded it during boot phase 2. I think that
>> withou
On Fri, 13 Sep 2024 16:31:36 GMT, Daniel Fuchs wrote:
>>> [...] I'd expect that libnet would have been loaded before we reach
>>> NTLMAuthentication.
>>
>> In the (as of now) penultimate webrev 4f47d5a (Merge),
>> `WindowsNativeDispatcher` loaded it during boot phase 2. I think that
>> withou
On Fri, 13 Sep 2024 16:08:50 GMT, Brian Burkhalter wrote:
>> I wonder - do you see any failure if you don't load libnet from there?
>
> Yes, there was an `UnsatisfiedLinkError` in the native method
> `isTrustedSiteAvailable()` in `NTLMAuthentication`.
> [...] I'd e
On Fri, 13 Sep 2024 16:08:50 GMT, Brian Burkhalter wrote:
>> I wonder - do you see any failure if you don't load libnet from there?
>
> Yes, there was an `UnsatisfiedLinkError` in the native method
> `isTrustedSiteAvailable()` in `NTLMAuthentication`.
> [...] I'd e
On Fri, 13 Sep 2024 16:08:50 GMT, Brian Burkhalter wrote:
>> I wonder - do you see any failure if you don't load libnet from there?
>
> Yes, there was an `UnsatisfiedLinkError` in the native method
> `isTrustedSiteAvailable()` in `NTLMAuthentication`.
> [...] I'd e
On Fri, 13 Sep 2024 16:06:26 GMT, Daniel Fuchs wrote:
>> hmm... I don't see any issue in adding the load call to
>> `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect
>> that libnet would have been loaded before we reach NTLMAuthentication.
>
> I wonder - do you see any f
On Fri, 13 Sep 2024 16:06:26 GMT, Daniel Fuchs wrote:
>> hmm... I don't see any issue in adding the load call to
>> `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect
>> that libnet would have been loaded before we reach NTLMAuthentication.
>
> I wonder - do you see any f
On Fri, 13 Sep 2024 16:06:26 GMT, Daniel Fuchs wrote:
>> hmm... I don't see any issue in adding the load call to
>> `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect
>> that libnet would have been loaded before we reach NTLMAuthentication.
>
> I wonder - do you see any f
On Tue, 10 Sep 2024 16:37:11 GMT, sbgoog wrote:
> FIleSystemPreferences.lockFile() catches an InterruptedException and just
> returns false, forgetting to re-interrupt the current thread. This leaves the
> caller with no way to observe that the thread was interrupted. This change
> restores th
On Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman wrote:
> Can you hold off integrating, I plan to go over the changes soon.
I don't plan to integrate until you have reviewed it. I set the minimum
reviewer count to 3 to avoid doing so accidentally.
-
PR Comment: https://git.openjdk.o
On Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman wrote:
> Can you hold off integrating, I plan to go over the changes soon.
I don't plan to integrate until you have reviewed it. I set the minimum
reviewer count to 3 to avoid doing so accidentally.
-
PR Comment: https://git.openjdk.o
On Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman wrote:
> Can you hold off integrating, I plan to go over the changes soon.
I don't plan to integrate until you have reviewed it. I set the minimum
reviewer count to 3 to avoid doing so accidentally.
-
PR Comment: https://git.openjdk.o
On Thu, 12 Sep 2024 02:05:50 GMT, Brian Burkhalter wrote:
>> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps
>> unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move
>> the load to a more appropriate location in t
On Thu, 12 Sep 2024 06:24:50 GMT, Daniel Jeliński wrote:
> Thanks for making the changes. LGTM, assuming that tests still pass.
The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any
case, I will run another round of tests before integrating.
> src/java.base/unix/native/
On Thu, 12 Sep 2024 02:05:50 GMT, Brian Burkhalter wrote:
>> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps
>> unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move
>> the load to a more appropriate location in t
On Thu, 12 Sep 2024 06:24:50 GMT, Daniel Jeliński wrote:
> Thanks for making the changes. LGTM, assuming that tests still pass.
The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any
case, I will run another round of tests before integrating.
> src/java.base/unix/native/
On Thu, 12 Sep 2024 02:05:50 GMT, Brian Burkhalter wrote:
>> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps
>> unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move
>> the load to a more appropriate location in t
On Thu, 12 Sep 2024 06:24:50 GMT, Daniel Jeliński wrote:
> Thanks for making the changes. LGTM, assuming that tests still pass.
The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any
case, I will run another round of tests before integrating.
> src/java.base/unix/native/
On Wed, 11 Sep 2024 19:22:00 GMT, Brian Burkhalter wrote:
>> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line
>> 1097:
>>
>>> 1095:
>>> 1096: static {
>>> 1097: jdk.internal.loader.BootLoader.loadLibrary("
On Wed, 11 Sep 2024 16:51:43 GMT, Daniel Jeliński wrote:
>> Yes, it still needs to be called in a few places, e.g., for classes whose
>> native component needs the `fdval()` and `handleval()` functions.
>
> that's a good point. The comment might need to be updated to reflect that.
Comments adde
On Wed, 11 Sep 2024 19:31:02 GMT, Brian Burkhalter wrote:
>> Just to be absolutely clear: All my other comments about removing unneeded
>> libraries were about libnio, not libjava. I realize I made the comment in
>> the PR next to libjava, but my intention was to ask if the
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last
On Tue, 10 Sep 2024 13:26:58 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.base/Lib.gmk line 81:
>>
>>> 79: libjava/nio/ch \
>>> 80: libnio/ch \
>>> 81: libnio/fs \
>>
>> libnio/fs is gone on all platforms other than aix; is this still necessary?
>
> We can't add e
On Tue, 10 Sep 2024 09:54:56 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
On Wed, 11 Sep 2024 16:51:43 GMT, Daniel Jeliński wrote:
>> Yes, it still needs to be called in a few places, e.g., for classes whose
>> native component needs the `fdval()` and `handleval()` functions.
>
> that's a good point. The comment might need to be updated to reflect that.
Comments adde
On Wed, 11 Sep 2024 19:22:00 GMT, Brian Burkhalter wrote:
>> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line
>> 1097:
>>
>>> 1095:
>>> 1096: static {
>>> 1097: jdk.internal.loader.BootLoader.loadLibrary("
On Wed, 11 Sep 2024 19:31:02 GMT, Brian Burkhalter wrote:
>> Just to be absolutely clear: All my other comments about removing unneeded
>> libraries were about libnio, not libjava. I realize I made the comment in
>> the PR next to libjava, but my intention was to ask if the
On Tue, 10 Sep 2024 13:26:58 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.base/Lib.gmk line 81:
>>
>>> 79: libjava/nio/ch \
>>> 80: libnio/ch \
>>> 81: libnio/fs \
>>
>> libnio/fs is gone on all platforms other than aix; is this still necessary?
>
> We can't add e
On Wed, 11 Sep 2024 19:22:00 GMT, Brian Burkhalter wrote:
>> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line
>> 1097:
>>
>>> 1095:
>>> 1096: static {
>>> 1097: jdk.internal.loader.BootLoader.loadLibrary("
On Tue, 10 Sep 2024 09:54:56 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
On Wed, 11 Sep 2024 16:51:43 GMT, Daniel Jeliński wrote:
>> Yes, it still needs to be called in a few places, e.g., for classes whose
>> native component needs the `fdval()` and `handleval()` functions.
>
> that's a good point. The comment might need to be updated to reflect that.
Comments adde
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last
On Wed, 11 Sep 2024 19:31:02 GMT, Brian Burkhalter wrote:
>> Just to be absolutely clear: All my other comments about removing unneeded
>> libraries were about libnio, not libjava. I realize I made the comment in
>> the PR next to libjava, but my intention was to ask if the
On Tue, 10 Sep 2024 13:26:58 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.base/Lib.gmk line 81:
>>
>>> 79: libjava/nio/ch \
>>> 80: libnio/ch \
>>> 81: libnio/fs \
>>
>> libnio/fs is gone on all platforms other than aix; is this still necessary?
>
> We can't add e
On Tue, 10 Sep 2024 09:54:56 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last
On Wed, 11 Sep 2024 19:28:39 GMT, Magnus Ihse Bursie wrote:
>> Apparently I did remove it from libjava and not libnio. It will be fixed in
>> the next commit. Thanks for being persistent.
>
> Just to be absolutely clear: All my other comments about removing unneeded
> libraries were about libni
On Wed, 11 Sep 2024 19:28:39 GMT, Magnus Ihse Bursie wrote:
>> Apparently I did remove it from libjava and not libnio. It will be fixed in
>> the next commit. Thanks for being persistent.
>
> Just to be absolutely clear: All my other comments about removing unneeded
> libraries were about libni
On Wed, 11 Sep 2024 19:28:39 GMT, Magnus Ihse Bursie wrote:
>> Apparently I did remove it from libjava and not libnio. It will be fixed in
>> the next commit. Thanks for being persistent.
>
> Just to be absolutely clear: All my other comments about removing unneeded
> libraries were about libni
On Tue, 10 Sep 2024 11:27:05 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
On Tue, 10 Sep 2024 11:27:05 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
On Tue, 10 Sep 2024 11:27:05 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
On Wed, 11 Sep 2024 16:48:24 GMT, Daniel Jeliński wrote:
>> From a clean build in the CI with `mswsock.lib` removed:
>>
>>
>> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019:
>> unresolved external symbol
>> TransmitFile referenced in function
>> Java_sun_nio_ch_FileDispatch
On Wed, 11 Sep 2024 16:48:24 GMT, Daniel Jeliński wrote:
>> From a clean build in the CI with `mswsock.lib` removed:
>>
>>
>> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019:
>> unresolved external symbol
>> TransmitFile referenced in function
>> Java_sun_nio_ch_FileDispatch
On Wed, 11 Sep 2024 16:48:24 GMT, Daniel Jeliński wrote:
>> From a clean build in the CI with `mswsock.lib` removed:
>>
>>
>> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019:
>> unresolved external symbol
>> TransmitFile referenced in function
>> Java_sun_nio_ch_FileDispatch
On Wed, 11 Sep 2024 06:00:23 GMT, Daniel Jeliński wrote:
>> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019:
>> unresolved external symbol TransmitFile`?
>
> Right. This PR moves FileDispatcherImpl.c to libjava, so
> FileDispatcherImpl.obj is no longer there. I'm guessi
On Wed, 11 Sep 2024 06:00:23 GMT, Daniel Jeliński wrote:
>> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019:
>> unresolved external symbol TransmitFile`?
>
> Right. This PR moves FileDispatcherImpl.c to libjava, so
> FileDispatcherImpl.obj is no longer there. I'm guessi
On Wed, 11 Sep 2024 06:00:23 GMT, Daniel Jeliński wrote:
>> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019:
>> unresolved external symbol TransmitFile`?
>
> Right. This PR moves FileDispatcherImpl.c to libjava, so
> FileDispatcherImpl.obj is no longer there. I'm guessi
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request with a new target base due to a
merge or a rebase.
On Tue, 10 Sep 2024 11:06:28 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
On Tue, 10 Sep 2024 11:06:28 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
On Tue, 10 Sep 2024 11:06:28 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out
>>
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request with a new target base due to a
merge or a rebase.
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request with a new target base due to a
merge or a rebase.
On Tue, 10 Sep 2024 17:33:22 GMT, Alan Bateman wrote:
> or truncating in the case of FOS
For that matter, I don't see where truncation is explicitly mentioned in the
FOS doc.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20878#discussion_r1752446236
On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has
On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has
On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has
On Fri, 6 Sep 2024 17:47:35 GMT, Brian Burkhalter wrote:
>> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
>> `isHidden` behave when the `File` represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one
&
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8339574: Replace "transparent
On Mon, 9 Sep 2024 17:10:13 GMT, Daniel Jeliński wrote:
> Does `File.exists` check the existence of the link target?
Yes. Verified on both Unix (macOS) and Windows 11.
-
PR Comment: https://git.openjdk.org/jdk/pull/20878#issuecomment-2338863163
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8339574: Revised class level doc o
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8339574: Add verbiage about links
On Thu, 5 Sep 2024 21:05:38 GMT, Brian Burkhalter wrote:
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
3a68877 addresses changes to `File` only; `FIS/FOS/RAF` are as yet unchanged.
---
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8339574: Add verbiage to cla
On Thu, 5 Sep 2024 21:05:38 GMT, Brian Burkhalter wrote:
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
If the `File` is a symbolic link, it looks after all that for most methods, the
final tar
Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
`isHidden` behave when the `File` represents a symbolic link.
-
Commit messages:
- 8339574: Behavior of File.is{Directory,File,Hidden} is not documented with
respect to symlinks
Changes: https://git.openjdk.
On Fri, 30 Aug 2024 20:59:18 GMT, Brian Burkhalter wrote:
> Return the final path derived from the string returned by `canonicalize0()`.
This pull request has now been integrated.
Changeset: 042053c3
Author: Brian Burkhalter
URL:
https://git.openjdk.org/jdk/com
> Return the final path derived from the string returned by `canonicalize0()`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8003887: Use Assumptions.assumeTrue() and other and other cleanup
-
Changes:
-
On Wed, 4 Sep 2024 08:40:36 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8003887: Test getCanonicalPath when the path contains links
>
> src/ja
On Tue, 3 Sep 2024 18:45:36 GMT, Brian Burkhalter wrote:
>> Return the final path derived from the string returned by `canonicalize0()`.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8003887: If
> Return the final path derived from the string returned by `canonicalize0()`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8003887: Test getCanonicalPath when the path contains links
-
Changes:
- all: ht
On Tue, 3 Sep 2024 16:00:53 GMT, Brian Burkhalter wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8003887: Free value allocated in and returned by getFinalPath()
>
> src/jav
> Return the final path derived from the string returned by `canonicalize0()`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8003887: If getFinalPath() fails, return the string returned by
canonicali
On Tue, 3 Sep 2024 15:56:36 GMT, Alan Bateman wrote:
> Can you check the tests in java/nio/file. I think they may skip if
> Files.createSymbolicLink fails, which it might do some Windows test machines
> but not others.
>From `Links.java`:
// Check if sym links are supported
tr
On Fri, 30 Aug 2024 21:39:47 GMT, Brian Burkhalter wrote:
>> Return the final path derived from the string returned by `canonicalize0()`.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8003887: Fr
On Mon, 2 Sep 2024 09:06:59 GMT, Alan Bateman wrote:
> Are you planning to add a test for this?
Links can't be created without elevated permissions so I need to investigate
how to do this. I think it's already done in some other tests.
-
PR Comment: https://git.openjdk.org/jdk/pul
> Return the final path derived from the string returned by `canonicalize0()`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8003887: Free value allocated in and returned by getFinalPath()
-
Changes:
-
On Fri, 30 Aug 2024 20:59:18 GMT, Brian Burkhalter wrote:
> Return the final path derived from the string returned by `canonicalize0()`.
The variable `GetFinalPathNameByHandle_func` is removed from the native code as
we no longer care about Windows versions preceding Vista.
-
1 - 100 of 1089 matches
Mail list logo
