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 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
On Wed, 27 Mar 2024 19:34:22 GMT, Erik Joelsson wrote:
>> make/modules/jdk.accessibility/Launcher.gmk line 30:
>>
>>> 28: ifeq ($(call isTargetOs, windows), true)
>>> 29: ACCESSIBILITY_SRCDIR := $(TOPDIR)/src/jdk.accessibility/windows/native
>>> 30:
>>
>> It looks like you determined that
On Wed, 27 Mar 2024 18:20:47 GMT, Magnus Ihse Bursie wrote:
>> This is a follow-up on JDK-8328680, making the same kind of cleanup to
>> jdk.accessibility. The code here needed more work than for the other
>> modules, so I wanted have it in a separate PR to get a more thorough review.
>
>
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 18:48:31 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix incorrect indentation
>
> make/modules/jdk.accessibility/Launcher.gmk line 30:
>
>> 28: ifeq ($(call
On Wed, 27 Mar 2024 18:20:47 GMT, Magnus Ihse Bursie wrote:
>> This is a follow-up on JDK-8328680, making the same kind of cleanup to
>> jdk.accessibility. The code here needed more work than for the other
>> modules, so I wanted have it in a separate PR to get a more thorough review.
>
>
On Wed, 27 Mar 2024 18:20:47 GMT, Magnus Ihse Bursie wrote:
>> This is a follow-up on JDK-8328680, making the same kind of cleanup to
>> jdk.accessibility. The code here needed more work than for the other
>> modules, so I wanted have it in a separate PR to get a more thorough review.
>
>
On Wed, 27 Mar 2024 17:45:25 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix incorrect indentation
>
> make/modules/jdk.accessibility/Launcher.gmk line 70:
>
>> 68: LIBS_windows
> This is a follow-up on JDK-8328680, making the same kind of cleanup to
> jdk.accessibility. The code here needed more work than for the other modules,
> so I wanted have it in a separate PR to get a more thorough review.
Magnus Ihse Bursie has updated the pull request incrementally with one
On Wed, 27 Mar 2024 12:00:28 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on JDK-8328680, making the same kind of cleanup to
> jdk.accessibility. The code here needed more work than for the other modules,
> so I wanted have it in a separate PR to get a more thorough review.
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
>
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1], then added
>> some minor changes
On Wed, 27 Mar 2024 14:47:00 GMT, Magnus Ihse Bursie wrote:
> At this point, I think I am not really qualified to continue the discussion.
>
> I will ask around inside Oracle to see if I can find someone who better
> understands the implications of the suggested libsleef integration (with or
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1], then added
>> some minor changes
On Tue, 26 Mar 2024 12:51:38 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8328680](https://bugs.openjdk.org/browse/JDK-8328680), making the same
> kind of cleanup to java.desktop. Some code needed more special treatment
> here, so there is some additional effects outside of
On Wed, 27 Mar 2024 10:39:35 GMT, Magnus Ihse Bursie wrote:
>> This is a follow-up on
>> [JDK-8328680](https://bugs.openjdk.org/browse/JDK-8328680), making the same
>> kind of cleanup to java.desktop. Some code needed more special treatment
>> here, so there is some additional effects outside
This is a follow-up on JDK-8328680, making the same kind of cleanup to
jdk.accessibility. The code here needed more work than for the other modules,
so I wanted have it in a separate PR to get a more thorough review.
-
Commit messages:
- 8329178: Clean up jdk.accessibility native
On Wed, 27 Mar 2024 12:00:28 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on JDK-8328680, making the same kind of cleanup to
> jdk.accessibility. The code here needed more work than for the other modules,
> so I wanted have it in a separate PR to get a more thorough review.
This is
On Wed, 27 Mar 2024 10:39:35 GMT, Magnus Ihse Bursie wrote:
>> This is a follow-up on
>> [JDK-8328680](https://bugs.openjdk.org/browse/JDK-8328680), making the same
>> kind of cleanup to java.desktop. Some code needed more special treatment
>> here, so there is some additional effects outside
On Tue, 30 Jan 2024 16:13:42 GMT, Hannes Wallnöfer wrote:
> This change adds the DejaVu web fonts that were previously maintained
> externally to the open repository so they are available both in JDK API
> documentation and any API documentation generated with the `javadoc` tool.
> All files
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
On Tue, 26 Mar 2024 23:38:07 GMT, Magnus Ihse Bursie wrote:
>> The code, prior to this PR, includes these lines:
>>
>> # The fast floor code loses precision.
>> LCMS_CFLAGS=-DCMS_DONT_USE_FAST_FLOOR -DCMS_NO_HALF_SUPPORT
>>
>>
>> This will overwrite the value of `LCMS_CFLAGS` as given in
> This is a follow-up on
> [JDK-8328680](https://bugs.openjdk.org/browse/JDK-8328680), making the same
> kind of cleanup to java.desktop. Some code needed more special treatment
> here, so there is some additional effects outside of the modules/java.desktop
> directory. The code was also in
On Tue, 26 Mar 2024 16:18:43 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on JDK-8328680, making the same kind of cleanup to
> jdk.jpackage. The code here needed more work than for the other modules, so I
> wanted have it in a separate PR to get a more thorough review.
This pull
> This is a follow-up on
> [JDK-8328680](https://bugs.openjdk.org/browse/JDK-8328680), making the same
> kind of cleanup to java.desktop. Some code needed more special treatment
> here, so there is some additional effects outside of the modules/java.desktop
> directory. The code was also in
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
On Wed, 27 Mar 2024 07:13:11 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
On Tue, 26 Mar 2024 20:03:36 GMT, Magnus Ihse Bursie wrote:
>> I see the advantage of collapsing self and parent into the same check, but
>> it doesn't seem like getting rid of pData is of much benefit, the checks for
>> null seem to remain the same either way
>
>> Sorry, I don't see a BOOL
On Tue, 26 Mar 2024 08:55:56 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less accepting of ill formed code, which will
> improve code quality on
On Tue, 26 Mar 2024 19:48:24 GMT, Magnus Ihse Bursie wrote:
> @MBaesken @RealCLanger I will need your assistance for testing this on AIX.
>
> I believe all refactorings I have done will keep the static jli build
> identical on AIX (apart from the name, of course). I have searched for jli
>
39 matches
Mail list logo
