Re: InetAddress API extension proposal
Hi Bernd,
Thank you for your comments! inet_addr() is POSIX.1, please see
https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
In its common implementation inet_addr() is just
u_long
inet_addr(cp)
register const char *cp;
{
struct in_addr val;
if (inet_aton(cp, &val))
return (val.s_addr);
return (INADDR_NONE);
}
In turn, inet_aton() is what's described - it either recognizes the
hex/octal bases or relies on strtoul().
RFC 3493 section 6.1 specifies a protocol-independent node name and
service name translation:
"If the specified address family is AF_INET or AF_UNSPEC,
address strings using Internet standard dot notation as specified in
inet_addr() are valid."
In the discussion of .ofLiteral() it was not concluded that
.ofPosixLiteral() would be insecure or undesirable. From the 'security
issues' point of view, it is a new method, it won't change the behavior
of old apps. If any code (a csrf filter) written in Java recognized
(knowing what it does) additional literal address formats, it would only
be an improvement (in detection). The good reason is bringing
compatibility with standard tools relying on inet_addr() into Java, that
would actually help overcoming the confusion between the standards. A
real world example could be a Java program parsing HOSTS file (it allows
hexadecimal address segments).
Am 26.03.24 um 20:10 schrieb Bernd Eckenfels:
Would be helpful to point to the posix standard/requirement which mandates
this. Do you mean a single Unix api description or a posix command spec? I
don’t think I know of any such things.
Wikipedia claims A POSIX-conforming variant of inet_aton, the inet_pton()
function, supports only the four-decimal variant of IP addresses.[10]
And can you also justify a bit more who needs that octal compatibility? Over
the years a lot of confusion (zero padding) and security issues (csrf filters
not catching all formats) have been found, so it’s really not a good idea to
implement it for no good reason. I think this was also the conclusion for the
ofLiteral() api.
Sergey Chernyshev wrote on 26. Mar 2024 17:51 (GMT +01:00):
Hello Core Libs Dev team,
I would like to propose a PR to extend the InetAddress API in JDK 23,
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Tue, 26 Mar 2024 21:11:09 GMT, Mandy Chung wrote:
>> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 68:
>>
>>> 66: int dotIndex = name.lastIndexOf('.');
>>> 67: String memberName =
>>> name.substring(openBracketIndex,dotIndex);
>>> 68: //Reconstruct .so() as
>>> .a()
>>
>> Do we really need to support libname.so(member)? Isn't it always
>> libname.a(member)?
>
> I think `mapAlternativeName` isn't needed at all. If
> `loadLibraryOnlyIfPresent` returns false, `System.load("libname.a(member)")`
> should be passed to dlopen directly. @suchismith1993 can verify it.
@mlchung Correct. But, if .so file is given and it is not present , it will
throw exception. So we should keep the mapAlternativeName for atleast .so to .a
mapping(without any members mentioned).
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540621304
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Tue, 26 Mar 2024 21:11:09 GMT, Mandy Chung wrote:
>> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 68:
>>
>>> 66: int dotIndex = name.lastIndexOf('.');
>>> 67: String memberName =
>>> name.substring(openBracketIndex,dotIndex);
>>> 68: //Reconstruct .so() as
>>> .a()
>>
>> Do we really need to support libname.so(member)? Isn't it always
>> libname.a(member)?
>
> I think `mapAlternativeName` isn't needed at all. If
> `loadLibraryOnlyIfPresent` returns false, `System.load("libname.a(member)")`
> should be passed to dlopen directly. @suchismith1993 can verify it.
@mlchung The first name constructed by Classloader is always lib.so. So
we need a way to map it to lib.a . Else it will search for .so and fail.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540650937
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 08:23:53 GMT, Suchismith Roy wrote:
>> I think `mapAlternativeName` isn't needed at all. If
>> `loadLibraryOnlyIfPresent` returns false, `System.load("libname.a(member)")`
>> should be passed to dlopen directly. @suchismith1993 can verify it.
>
> @mlchung The first name constructed by Classloader is always lib.so. So
> we need a way to map it to lib.a . Else it will search for .so and fail.
Right, the `loadLibraryOnlyIfPresent` change is sufficient for
`System.load("libname.a(member)")` support. I don't know how common ".a"
without member specification ist, but that may make sense. It sounds similar to
what was done for MacOS with
https://github.com/openjdk/jdk/commit/1e4dfcfbf00a9b17418bccc0dc746fd9a71f3a06.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540686268
Re: RFR: 8327791: Optimization for new BigDecimal(String) [v16]
On Wed, 20 Mar 2024 22:56:38 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the length is greater than 18, create a char[]
>>
>>
>> boolean isCompact = (len <= MAX_COMPACT_DIGITS); // 18
>> if (!isCompact) {
>> // ...
>> } else {
>> char[] coeff = new char[len]; // allocate char[]
>> // ...
>> }
>>
>>
>> This PR eliminates the two memory allocations mentioned above, resulting in
>> an approximate 60% increase in performance..
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> use while instead for
I also agree that public constructors should be a new PR. I'm waiting for this
PR to be merged and then submit a new PR.
-
PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-2022525905
Re: RFR: 8328995: launcher can't open jar files where the offset of the manifest is >4GB
On Wed, 27 Mar 2024 03:19:47 GMT, Jiangli Zhou wrote: >> This change fixes a zip64 bug in the launcher that is prevent it from >> reading the manifest of jars where the 'relative offset of local header' >> field in the central directory entry is >4GB. As described in APPNOTE.TXT >> 4.5.3, the offset is too large to be stored in the central directory it is >> stored in a 'Zip64 Extended Information Extra Field'. > > src/java.base/share/native/libjli/manifest_info.h line 146: > >> 144: * Macros for getting Extensible Data Fields >> 145: */ >> 146: #define ZIPEXT_HDR(b) SH(b, 0) /* Header ID */ > > How about naming the macros as ZIP64EXT_HDR and ZIP64EXT_SIZ? My thinking was that all extensible data fields start with a header with an id and a length, and these macros are used to iterate through the extra fields to find the zip64 extended information extra field, so these macros aren't zip64-specific. - PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1541364405
RFR: 8324651: Compiler Implementation for Derived Record Creation (Preview)
This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is: https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html The current CSR is here: https://bugs.openjdk.org/browse/JDK-8328637 The patch is mostly straightforward, with two notable changes: - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago. - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation. - Commit messages: - Removing whitespace - Cleanup. - Cleanup, bugfixes. - Adding tests. - Adding examples. - More correct handling of exceptions in derived record creation expression; optimizing the resulting bytecode. - Javadoc cleanup. - Merge branch 'master' into wthexp - Adding missing file. - Cleanup. - ... and 11 more: https://git.openjdk.org/jdk/compare/0c1b254b...a61682ff Changes: https://git.openjdk.org/jdk/pull/18509/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324651 Stats: 1551 lines in 41 files changed: 1481 ins; 20 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/18509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509 PR: https://git.openjdk.org/jdk/pull/18509
Re: RFR: 8328995: launcher can't open jar files where the offset of the manifest is >4GB [v2]
> This change fixes a zip64 bug in the launcher that is prevent it from reading > the manifest of jars where the 'relative offset of local header' field in the > central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the > offset is too large to be stored in the central directory it is stored in a > 'Zip64 Extended Information Extra Field'. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Fix disk number size - Changes: - all: https://git.openjdk.org/jdk/pull/18479/files - new: https://git.openjdk.org/jdk/pull/18479/files/8f908a0e..6b13ecc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=00-01 Stats: 19 lines in 1 file changed: 8 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18479/head:pull/18479 PR: https://git.openjdk.org/jdk/pull/18479
Re: RFR: 8328995: launcher can't open jar files where the offset of the manifest is >4GB [v2]
On Wed, 27 Mar 2024 03:18:42 GMT, Jiangli Zhou wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix disk number size > > src/java.base/share/native/libjli/manifest_info.h line 59: > >> 57: #define ZIP64_EXTID 1 // Extra field Zip64 header ID >> 58: >> 59: #define ZIP64_EXTMAXLEN 36 // Maximum Zip64 extra field length > > The fields described in APPNOTE-6.3.9.TXT 4.5.3 are total 32 bytes. Any other > additional fields in the Zip64 extended information? > > > Value Size Description > - --- > (ZIP64) 0x0001 2 bytesTag for this "extra" block type > Size 2 bytesSize of this "extra" block > Original > Size 8 bytesOriginal uncompressed file size > Compressed > Size 8 bytesSize of compressed data > Relative Header > Offset 8 bytesOffset of local header record > Disk Start > Number 4 bytesNumber of the disk on which > this file starts Thanks for the catch, I had missed that the disk start number is 4 bytes and not 8. I pushed a commit. I also removed some unused references to the disk number, which is only being used to validate the size of the zip64 extended info. - PR Review Comment: https://git.openjdk.org/jdk/pull/18479#discussion_r1541404663
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 08:47:10 GMT, Martin Doerr wrote:
>> @mlchung The first name constructed by Classloader is always lib.so.
>> So we need a way to map it to lib.a . Else it will search for .so and
>> fail.
>
> Right, the `loadLibraryOnlyIfPresent` change is sufficient for
> `System.load("libname.a(member)")` support. I don't know how common ".a"
> without member specification ist, but that may make sense. It sounds similar
> to what was done for MacOS with
> https://github.com/openjdk/jdk/commit/1e4dfcfbf00a9b17418bccc0dc746fd9a71f3a06.
> So we should keep the mapAlternativeName for atleast .so to .a
> mapping(without any members mentioned).
"libname.so(member_name)" is not a valid library name. No reason why
`System.load` has to support it.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541477181
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 16:44:34 GMT, Mandy Chung wrote: > > So we should keep the mapAlternativeName for atleast .so to .a > > mapping(without any members mentioned). > > "libname.so(member_name)" is not a valid library name. No reason why > `System.load` has to support it. We are not supporting that. Are you referring to the comment in the code ? Yeah it should be resconstruction of libname(member_name).so , which is the first filename the classLoader constructs. - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541502377
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:01:30 GMT, Suchismith Roy wrote:
>>> So we should keep the mapAlternativeName for atleast .so to .a
>>> mapping(without any members mentioned).
>>
>> "libname.so(member_name)" is not a valid library name. No reason why
>> `System.load` has to support it.
>
>> > So we should keep the mapAlternativeName for atleast .so to .a
>> > mapping(without any members mentioned).
>>
>> "libname.so(member_name)" is not a valid library name. No reason why
>> `System.load` has to support it.
>
> We are not supporting that. Are you referring to the comment in the code ?
> Yeah it should be resconstruction of libname(member_name).so , which is the
> first filename the classLoader constructs.
I think we both mean that the `if (name.contains("("))` block should get
removed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541509898
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:06:49 GMT, Martin Doerr wrote:
>>> > So we should keep the mapAlternativeName for atleast .so to .a
>>> > mapping(without any members mentioned).
>>>
>>> "libname.so(member_name)" is not a valid library name. No reason why
>>> `System.load` has to support it.
>>
>> We are not supporting that. Are you referring to the comment in the code ?
>> Yeah it should be resconstruction of libname(member_name).so , which is the
>> first filename the classLoader constructs.
>
> I think we both mean that the `if (name.contains("("))` block should get
> removed.
> We are not supporting that. Are you referring to the comment in the code ?
> Yeah it should be resconstruction of libname(member_name).so , which is the
> first filename the classLoader constructs.
Note that `System.mapLibraryName` and `mapAlternativeName` are called for
`System.loadLibrary` (i.e. prepending `lib` and appending `.so`).
"libname(member_name)" is not a valid name and no reason for
`System.loadLibrary` to support it.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541525247
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v6]
> Allow support for both .a and .so files in AIX. > If .so file is not found, allow fallback to .a extension. > JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516) Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - remove member check - update comment - coding style - set false - restore fil - remove member check code - trraling spaces - trailing spaces - remove space - remove debug print lines - ... and 6 more: https://git.openjdk.org/jdk/compare/d0a26503...4c068e78 - Changes: https://git.openjdk.org/jdk/pull/17945/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17945&range=05 Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:19:31 GMT, Mandy Chung wrote:
>>> We are not supporting that. Are you referring to the comment in the code ?
>>> Yeah it should be resconstruction of libname(member_name).so , which is the
>>> first filename the classLoader constructs.
>>
>> Note that `System.mapLibraryName` and `mapAlternativeName` are called for
>> `System.loadLibrary` (i.e. prepending `lib` and appending `.so`).
>> "libname(member_name)" is not a valid name and no reason for
>> `System.loadLibrary` to support it.
>
>> I think we both mean that the if (name.contains("(")) block should get
>> removed.
>
> Because of the VM support, we can remove `mapAlternativeName` completely.
Oh ok.Yes i have removed that now. You mean ,load library wont support it, but
load will be able to support it since the loadLibraryIfPresent is returned
false now.
Now the loadLibrary can only handle .so to .a mapping due to mapAlternativeName
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541534243
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:18:10 GMT, Mandy Chung wrote:
>> I think we both mean that the `if (name.contains("("))` block should get
>> removed.
>
>> We are not supporting that. Are you referring to the comment in the code ?
>> Yeah it should be resconstruction of libname(member_name).so , which is the
>> first filename the classLoader constructs.
>
> Note that `System.mapLibraryName` and `mapAlternativeName` are called for
> `System.loadLibrary` (i.e. prepending `lib` and appending `.so`).
> "libname(member_name)" is not a valid name and no reason for
> `System.loadLibrary` to support it.
> I think we both mean that the if (name.contains("(")) block should get
> removed.
Because of the VM support, we can remove `mapAlternativeName` completely.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541531589
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:27:43 GMT, Suchismith Roy wrote: >> Oh ok.Yes i have removed that now. You mean ,load library wont support it, >> but load will be able to support it since the loadLibraryIfPresent is >> returned false now. >> >> Now the loadLibrary can only handle .so to .a mapping due to >> mapAlternativeName > >> Because of the VM support, we can remove `mapAlternativeName` completely. > > Does VM provide support for mapping .so to .a files ? We still have cases > where the entire .a file is shared and don't need to mention the member. libsystemInfo.a is one use case ,i got after discussion with our teams, which actually raised this issue in J9. So there are cases where pure .a files exist. - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541548250
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:20:22 GMT, Suchismith Roy wrote:
>>> I think we both mean that the if (name.contains("(")) block should get
>>> removed.
>>
>> Because of the VM support, we can remove `mapAlternativeName` completely.
>
> Oh ok.Yes i have removed that now. You mean ,load library wont support it,
> but load will be able to support it since the loadLibraryIfPresent is
> returned false now.
>
> Now the loadLibrary can only handle .so to .a mapping due to
> mapAlternativeName
> Because of the VM support, we can remove `mapAlternativeName` completely.
Does VM provide support for mapping .so to .a files ? We still have cases where
the entire .a file is shared and don't need to mention the member.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541544958
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:30:13 GMT, Suchismith Roy wrote: >>> Because of the VM support, we can remove `mapAlternativeName` completely. >> >> Does VM provide support for mapping .so to .a files ? We still have cases >> where the entire .a file is shared and don't need to mention the member. > > libsystemInfo.a is one use case ,i got after discussion with our teams, which > actually raised this issue in J9. So there are cases where pure .a files > exist. AFAICT from your fix for [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) commit [e85355ad](https://github.com/openjdk/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab). But it needs verification as I suggest (see https://github.com/openjdk/jdk/pull/17945#issuecomment-2019965401). - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541555855
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:34:22 GMT, Mandy Chung wrote: >> libsystemInfo.a is one use case ,i got after discussion with our teams, >> which actually raised this issue in J9. So there are cases where pure .a >> files exist. > > AFAICT from your fix for > [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) commit > [e85355ad](https://github.com/openjdk/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab). > > But it needs verification as I suggest (see > https://github.com/openjdk/jdk/pull/17945#issuecomment-2019965401). @mlchung [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) is solving the .so to .a mapping at hotspot level. But if we still call loadLibrary() , with a .so, which has an equivalent .a file, it will fail. What kind of verification are you mentioning ? We do have use cases where we have pure .a files. libsystemInfo.a being one of them, as i confirmed from our teams. - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541566885
Re: RFR: 8328995: launcher can't open jar files where the offset of the manifest is >4GB [v3]
> This change fixes a zip64 bug in the launcher that is prevent it from reading > the manifest of jars where the 'relative offset of local header' field in the > central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the > offset is too large to be stored in the central directory it is stored in a > 'Zip64 Extended Information Extra Field'. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Make cendsk an unsigned short - Changes: - all: https://git.openjdk.org/jdk/pull/18479/files - new: https://git.openjdk.org/jdk/pull/18479/files/6b13ecc2..7b599c9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18479&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18479/head:pull/18479 PR: https://git.openjdk.org/jdk/pull/18479
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:40:09 GMT, Suchismith Roy wrote:
>> AFAICT from your fix for
>> [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) commit
>> [e85355ad](https://github.com/openjdk/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab).
>>
>> But it needs verification as I suggest (see
>> https://github.com/openjdk/jdk/pull/17945#issuecomment-2019965401).
>
> @mlchung [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) is
> solving the .so to .a mapping at hotspot level. But if we still call
> loadLibrary() , with a .so, which has an equivalent .a file, it will fail.
>
> What kind of verification are you mentioning ? We do have use cases where we
> have pure .a files. libsystemInfo.a being one of them, as i confirmed from
> our teams.
You can try with a simple program calling `System.loadLibrary("systeminfo")`
with just `loadLibraryOnlyIfPresent` change.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541570578
Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue) [v5]
> This PR adds an internal method to calculate hash code from the provided > integer array, offset and length into that array, and the initial hash code > value. > > Current options for calculating a hash code for int[] are inflexible. It's > either ArraysSupport.vectorizedHashCode with an offset, length and initial > value, or Arrays.hashCode with just an array. > > For an arbitrary int[], unconditional vectorization might be unwarranted or > puzzling. Unfortunately, it's the only hash code method that operates on an > array subrange or accepts the initial hash code value. > > A more convenient method could be added and then used, for example, here: > > * > https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083 > > * > https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680 > > * > https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362 > > This PR adds such a method and provides tests for it. Additionally, this PR > adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, > behaviour which was specified but untested. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into 8311864 - Merge branch 'master' into 8311864 - Merge remote-tracking branch 'jdk/master' into 8311864 - Merge branch 'master' into 8311864 - Initial commit - Changes: - all: https://git.openjdk.org/jdk/pull/14831/files - new: https://git.openjdk.org/jdk/pull/14831/files/e55dc5c1..2d06e03a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14831&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14831&range=03-04 Stats: 582641 lines in 7412 files changed: 101141 ins; 127425 del; 354075 mod Patch: https://git.openjdk.org/jdk/pull/14831.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14831/head:pull/14831 PR: https://git.openjdk.org/jdk/pull/14831
RFR: 8326627: Document Double/Float.valueOf(String) behaviour for numeric strings with non-ASCII digits
Clarifying the behavior for non-ASCII digits in Double/Float.valueOf(String) method descriptions. A draft CSR has also been created. - Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/18526/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18526&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326627 Stats: 33 lines in 4 files changed: 22 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/18526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18526/head:pull/18526 PR: https://git.openjdk.org/jdk/pull/18526
Re: RFR: JDK-8327640: Allow NumberFormat strict parsing [v5]
> Please review this PR and associated
> [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict
> parsing for NumberFormat.
>
> The concrete subclasses that will utilize this leniency value are
> `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing
> to be used as an input validation technique for localized formatted numbers.
> The default leniency mode will remain lenient, and can only be set to strict
> through an intentional `setLenient(boolean)` method call. Leniency operates
> differently based off the values returned by `isGroupingUsed()`,
> `getGroupingSize()`, and `isParseIntegerOnly()`.
>
> Below is an example of the change, the CSR can be viewed for further detail.
>
>
> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // returns 1000.23
> fmt.setLenient(false);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
> fmt.setGroupingSize(2);
> fmt.parse("12,34,567"); // throws ParseException
> fmt.setParseIntegerOnly(true)
> fmt.parse("12,34.56"); // throws ParseException
> fmt.parse("12,34"); // successfully returns the Number 1234
>
>
> The associated tests are all localized, and the data is converted properly
> during runtime.
Justin Lu has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains 13 additional commits since the
last revision:
- improve wording consistency and see tags
- Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
- revert cleanup changes; (to go into a separate change)
- use directed 'inheritDoc' tag
- update example for lenient parsing
- replace protected field for private fields in subclasses for consistency
- drop Format implNote as well
- setStrict and isStrict should be optional in NumberFormat
- specify and throw UOE as default
- override and implement in dFmt and cmpctNFmt
parseStrict should be protected, and utilized by subclasses. The public
methods should just
serve as API.
- Re-work specification wording from Format down to subclasses
- implement white space suggestions
- ... and 3 more: https://git.openjdk.org/jdk/compare/c8a9b97f...3f2b097a
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18339/files
- new: https://git.openjdk.org/jdk/pull/18339/files/4edb4802..3f2b097a
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=04
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=03-04
Stats: 349232 lines in 2746 files changed: 15275 ins; 10415 del; 323542 mod
Patch: https://git.openjdk.org/jdk/pull/18339.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/18339/head:pull/18339
PR: https://git.openjdk.org/jdk/pull/18339
Integrated: JDK-8327875: ChoiceFormat should advise throwing UnsupportedOperationException for unused methods
On Tue, 26 Mar 2024 20:50:10 GMT, Justin Lu wrote: > Please review this PR which advises ChoiceFormat subclasses throw > `UnsupportedOperationException` for unused inherited methods. > > The CSR covers the proposed wording, and the reasons as to why this is a > specification and not an implementation update. In addition, the > `api/implNote` tags have been moved to the bottom of the class description, > as they are no longer only relevant to the pattern section, (where they were > previously located). This pull request has now been integrated. Changeset: 0cb0b5db Author:Justin Lu URL: https://git.openjdk.org/jdk/commit/0cb0b5db2ac0f9b5a8fe40c5be5f7b12124fe402 Stats: 25 lines in 1 file changed: 15 ins; 10 del; 0 mod 8327875: ChoiceFormat should advise throwing UnsupportedOperationException for unused methods Reviewed-by: naoto - PR: https://git.openjdk.org/jdk/pull/18499
Re: RFR: 8326627: Document Double/Float.valueOf(String) behaviour for numeric strings with non-ASCII digits
On Wed, 27 Mar 2024 19:58:17 GMT, Naoto Sato wrote: > Clarifying the behavior for non-ASCII digits in Double/Float.valueOf(String) > method descriptions. A draft CSR has also been created. Associated CSR also Reviewed. I like the relocation of existing text to the more appropriate `@apiNote`. The example provides additional clarity. - Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18526#pullrequestreview-1964850180
RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
Please review the updates to support a proposed new
`-Xlint:dangling-doc-comments` option.
The work can be thought of as in 3 parts:
1. An update to the `javac` internal class `DeferredLintHandler` so that it is
possible to specify the appropriately configured `Lint` object when it is time
to consider whether to generate the diagnostic or not.
2. Updates to the `javac` front end to record "dangling docs comments" found
near the beginning of a declaration, and to report them using an instance of
`DeferredLintHandler`. This allows the warnings to be enabled or disabled using
the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure
for handling dangling doc comments is described in this comment in
`JavacParser`.
* Dangling documentation comments are handled as follows.
* 1. {@code Scanner} adds all doc comments to a queue of
* recent doc comments. The queue is flushed whenever
* it is known that the recent doc comments should be
* ignored and should not cause any warnings.
* 2. The primary documentation comment is the one obtained
* from the first token of any declaration.
* (using {@code token.getDocComment()}.
* 3. At the end of the "signature" of the declaration
* (that is, before any initialization or body for the
* declaration) any other "recent" comments are saved
* in a map using the primary comment as a key,
* using this method, {@code saveDanglingComments}.
* 4. When the tree node for the declaration is finally
* available, and the primary comment, if any,
* is "attached", (in {@link #attach}) any related
* dangling comments are also attached to the tree node
* by registering them using the {@link #deferredLintHandler}.
* 5. (Later) Warnings may be genereated for the dangling
* comments, subject to the {@code -Xlint} and
* {@code @SuppressWarnings}.
3. Updates to the make files to disable the warnings in modules for which the
warning is generated. This is often because of the confusing use of `/**` to
create box or other standout comments.
-
Commit messages:
- JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
Changes: https://git.openjdk.org/jdk/pull/18527/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8303689
Stats: 477 lines in 60 files changed: 368 ins; 5 del; 104 mod
Patch: https://git.openjdk.org/jdk/pull/18527.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527
PR: https://git.openjdk.org/jdk/pull/18527
Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when it is
> time to consider whether to generate the diagnostic or not.
>
> 2. Updates to the `javac` front end to record "dangling docs comments" found
> near the beginning of a declaration, and to report them using an instance of
> `DeferredLintHandler`. This allows the warnings to be enabled or disabled
> using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The
> procedure for handling dangling doc comments is described in this comment in
> `JavacParser`.
>
> * Dangling documentation comments are handled as follows.
> * 1. {@code Scanner} adds all doc comments to a queue of
> * recent doc comments. The queue is flushed whenever
> * it is known that the recent doc comments should be
> * ignored and should not cause any warnings.
> * 2. The primary documentation comment is the one obtained
> * from the first token of any declaration.
> * (using {@code token.getDocComment()}.
> * 3. At the end of the "signature" of the declaration
> * (that is, before any initialization or body for the
> * declaration) any other "recent" comments are saved
> * in a map using the primary comment as a key,
> * using this method, {@code saveDanglingComments}.
> * 4. When the tree node for the declaration is finally
> * available, and the primary comment, if any,
> * is "attached", (in {@link #attach}) any related
> * dangling comments are also attached to the tree node
> * by registering them using the {@link #deferredLintHandler}.
> * 5. (Later) Warnings may be genereated for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` to
> create box or other standout comments.
Would this be the first lint -- not doclint -- warning related to comments, let
alone doc comments?
-
PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024106466
Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when it is
> time to consider whether to generate the diagnostic or not.
>
> 2. Updates to the `javac` front end to record "dangling docs comments" found
> near the beginning of a declaration, and to report them using an instance of
> `DeferredLintHandler`. This allows the warnings to be enabled or disabled
> using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The
> procedure for handling dangling doc comments is described in this comment in
> `JavacParser`.
>
> * Dangling documentation comments are handled as follows.
> * 1. {@code Scanner} adds all doc comments to a queue of
> * recent doc comments. The queue is flushed whenever
> * it is known that the recent doc comments should be
> * ignored and should not cause any warnings.
> * 2. The primary documentation comment is the one obtained
> * from the first token of any declaration.
> * (using {@code token.getDocComment()}.
> * 3. At the end of the "signature" of the declaration
> * (that is, before any initialization or body for the
> * declaration) any other "recent" comments are saved
> * in a map using the primary comment as a key,
> * using this method, {@code saveDanglingComments}.
> * 4. When the tree node for the declaration is finally
> * available, and the primary comment, if any,
> * is "attached", (in {@link #attach}) any related
> * dangling comments are also attached to the tree node
> * by registering them using the {@link #deferredLintHandler}.
> * 5. (Later) Warnings may be genereated for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` to
> create box or other standout comments.
Javadoc changes look trivially good. I only note that the javadoc man page diff
contains some unrelated changes.
-
PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024116236
Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when it is
> time to consider whether to generate the diagnostic or not.
>
> 2. Updates to the `javac` front end to record "dangling docs comments" found
> near the beginning of a declaration, and to report them using an instance of
> `DeferredLintHandler`. This allows the warnings to be enabled or disabled
> using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The
> procedure for handling dangling doc comments is described in this comment in
> `JavacParser`.
>
> * Dangling documentation comments are handled as follows.
> * 1. {@code Scanner} adds all doc comments to a queue of
> * recent doc comments. The queue is flushed whenever
> * it is known that the recent doc comments should be
> * ignored and should not cause any warnings.
> * 2. The primary documentation comment is the one obtained
> * from the first token of any declaration.
> * (using {@code token.getDocComment()}.
> * 3. At the end of the "signature" of the declaration
> * (that is, before any initialization or body for the
> * declaration) any other "recent" comments are saved
> * in a map using the primary comment as a key,
> * using this method, {@code saveDanglingComments}.
> * 4. When the tree node for the declaration is finally
> * available, and the primary comment, if any,
> * is "attached", (in {@link #attach}) any related
> * dangling comments are also attached to the tree node
> * by registering them using the {@link #deferredLintHandler}.
> * 5. (Later) Warnings may be genereated for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` to
> create box or other standout comments.
src/jdk.javadoc/share/man/javadoc.1 line 111:
> 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more
> 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R].
> 111: Within a source file, you may use suppress any warnings generated by
Typo?
Suggestion:
Within a source file, you may suppress any warnings generated by
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542131487
Re: InetAddress API extension proposal
On 27/03/2024 17:05, Sergey Chernyshev wrote: In the discussion of .ofLiteral() it was not concluded that .ofPosixLiteral() would be insecure or undesirable. From the 'security issues' point of view, it is a new method, it won't change the behavior of old apps. If any code (a csrf filter) written in Java recognized (knowing what it does) additional literal address formats, it would only be an improvement (in detection). The good reason is bringing compatibility with standard tools relying on inet_addr() into Java, that would actually help overcoming the confusion between the standards. A real world example could be a Java program parsing HOSTS file (it allows hexadecimal address segments). Again, please start a new discussion on net-dev. It would be helpful to include a summary on the behavior between different operating system as it's that difference, and the parsing of ambiguous corner cases, where the security researchers will focus on. -Alan
Re: RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
On Wed, 27 Mar 2024 22:41:33 GMT, Pavel Rappo wrote: > Would this be the first lint -- not doclint -- warning related to comments, > let alone doc comments? No. `-Xlint:dep-ann` correlates `@Deprecated` annotations with `@deprecated` tags in doc comments. > src/jdk.javadoc/share/man/javadoc.1 line 111: > >> 109: source code with the \f[V]javac\f[R] option \f[V]-Xlint\f[R], or more >> 110: specifically, \f[V]-Xlint:dangling-doc-comments\f[R]. >> 111: Within a source file, you may use suppress any warnings generated by > > Typo? > Suggestion: > > Within a source file, you may suppress any warnings generated by Thanks; I'll check the underlying original. - PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2024162355 PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1542157047
