This question was brought up in https://github.com/openjdk/jdk/pull/15096,
the issue is that awt.dll has historically tried to avoid depending on
msvcp.dll, and as
https://github.com/openjdk/jdk/pull/15096#issuecomment-1796303631 points
out, it is unclear whether it is now safe to introduce a
On Thu, 9 Nov 2023 16:39:58 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Customize support for Markdown headings
>
> test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdown.java line
On Wed, 8 Nov 2023 17:37:25 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix whitespace
>
> test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 96:
>
>> 94:
On Wed, 8 Nov 2023 17:28:48 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix whitespace
>
> test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 82:
>
>> 80:
>> 81:
On Wed, 8 Nov 2023 17:28:10 GMT, Pavel Rappo wrote:
>> test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 64:
>>
>>> 62:
>>> 63: @Test
>>> 64: public void testFindStandardTransformer_raw() throws Exception {
>>
>> Checked exceptions are not thrown:
>>
On Wed, 15 Nov 2023 00:09:17 GMT, Jonathan Gibbons wrote:
>> test/langtools/tools/javac/doctree/FirstSentenceTest.java line 423:
>>
>>> 421: DocComment[DOC_COMMENT, pos:0
>>> 422: firstSentence: 1
>>> 423: RawText[MARKDOWN, pos:0, abc.|def.]
>>
>> It took me a while to understand why
On Wed, 8 Nov 2023 17:24:46 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix whitespace
>
> test/langtools/jdk/javadoc/tool/testTransformer/TestTransformer.java line 37:
>
>> 35:
>> 36:
On Wed, 8 Nov 2023 10:59:58 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix whitespace
>
> test/langtools/tools/javac/doctree/FirstSentenceTest.java line 423:
>
>> 421:
On Wed, 8 Nov 2023 10:31:14 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix whitespace
>
> test/langtools/tools/javac/doctree/MDPrinter.java line 67:
>
>> 65: * Conceptually based on
> 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`
>
> 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`
>
The goal is to develop faster sort routines for x86_64 CPUs by taking advantage
of AVX2 instructions. This enhancement provides an order of magnitude speedup
for Arrays.sort() using int, long, float and double arrays.
For serial sort on random data, this PR shows upto ~7.5x improvement for
On 2023-11-14 15:41, Magnus Ihse Bursie wrote:
However, I'd like to have some more investigation into how cl.exe
picks the language.
Is it a hard-coded behavior that it always picks English if it is
installed? If so, it does not really make sense to have more than one
language pack
On 2023-11-14 15:41, Magnus Ihse Bursie wrote:
On 2023-11-06 15:56, 吴国璋 wrote:
Thanks Magnus for your opionion. Just one thing to point out:
reaching out to Microsoft is not needed. Here is the reason:
If Visual Studio is installed with both English and another language
pack, cl.exe will
On 2023-11-06 15:56, 吴国璋 wrote:
Thanks Magnus for your opionion. Just one thing to point out: reaching
out to Microsoft is not needed. Here is the reason:
If Visual Studio is installed with both English and another language
pack, cl.exe will present itself in English while running configure.
On Tue, 14 Nov 2023 11:04:43 GMT, Aleksey Shipilev wrote:
>> Looking at why GHA did not catch
>> [JDK-8320050](https://bugs.openjdk.org/browse/JDK-8320050), even though it
>> builds hotspot, I realized we do not configure the build with gtest, which
>> means we skip the build checks for gtest
On Tue, 14 Nov 2023 11:04:43 GMT, Aleksey Shipilev wrote:
>> Looking at why GHA did not catch
>> [JDK-8320050](https://bugs.openjdk.org/browse/JDK-8320050), even though it
>> builds hotspot, I realized we do not configure the build with gtest, which
>> means we skip the build checks for gtest
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
It does beg the question though: Why is AIX not using dynamic loading of the
standard library?
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
Okay, I checked the spec for `nativeLinker()`.
* @implNote The libraries exposed by the
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
I've done another pass of reading through all comments and background. I think
we're not even
On Tue, 14 Nov 2023 11:07:08 GMT, Magnus Ihse Bursie wrote:
> (If you feel the urge to open a PR before all testing is complete, you can
> mark it as draft to avoid having it being reviewed before it is ready to
> review...)
Yeah, I meant to open as draft to get testing done, but misclicked.
On Tue, 14 Nov 2023 11:04:43 GMT, Aleksey Shipilev wrote:
>> Looking at why GHA did not catch
>> [JDK-8320050](https://bugs.openjdk.org/browse/JDK-8320050), even though it
>> builds hotspot, I realized we do not configure the build with gtest, which
>> means we skip the build checks for gtest
On Tue, 14 Nov 2023 10:06:00 GMT, Aleksey Shipilev wrote:
> Looking at why GHA did not catch
> [JDK-8320050](https://bugs.openjdk.org/browse/JDK-8320050), even though it
> builds hotspot, I realized we do not configure the build with gtest, which
> means we skip the build checks for gtest VM.
> Looking at why GHA did not catch
> [JDK-8320050](https://bugs.openjdk.org/browse/JDK-8320050), even though it
> builds hotspot, I realized we do not configure the build with gtest, which
> means we skip the build checks for gtest VM. It would be useful to
> cross-compile with all tests
On Tue, 14 Nov 2023 10:06:00 GMT, Aleksey Shipilev wrote:
> Looking at why GHA did not catch
> [JDK-8320050](https://bugs.openjdk.org/browse/JDK-8320050), even though it
> builds hotspot, I realized we do not configure the build with gtest, which
> means we skip the build checks for gtest VM.
Looking at why GHA did not catch
[JDK-8320050](https://bugs.openjdk.org/browse/JDK-8320050), even though it
builds hotspot, I realized we do not configure the build with gtest, which
means we skip the build checks for gtest VM. It would be useful to
cross-compile with all tests enabled, even
26 matches
Mail list logo
