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.
>
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)
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
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
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
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
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
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
> 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
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=18526=00
> 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
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
> 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
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
>
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.
>
>
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
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
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
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
> 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
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
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
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
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
>
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
> 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
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
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
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
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
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:
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:
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;
33 matches
Mail list logo
