On Wed, 20 Mar 2024 15:54:12 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
On Tue, 26 Mar 2024 23:10:44 GMT, Magnus Ihse Bursie wrote:
>> This took me a while to decode. The old code will unconditionally override
>> `LCMS_CFLAGS` which means whatever value it gets in configure is
>> overwritten. That certainly seems like a bug.
>>
>> Your current patch clears the
On Tue, 26 Mar 2024 22:01:33 GMT, Erik Joelsson 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 Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
On Tue, 26 Mar 2024 19:36:04 GMT, Phil Race wrote:
>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 280:
>>
>>> 278: # as includes, instead the system headers should be used.
>>> 279: LIBLCMS_HEADERS_FROM_SRC := false
>>> 280: # FIXME: Keep old behavior and reset LCMS_CFLAGS. This
On Tue, 26 Mar 2024 19:19:14 GMT, Phil Race 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 the
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 Tue, 26 Mar 2024 19:36:04 GMT, Phil Race wrote:
>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 280:
>>
>>> 278: # as includes, instead the system headers should be used.
>>> 279: LIBLCMS_HEADERS_FROM_SRC := false
>>> 280: # FIXME: Keep old behavior and reset LCMS_CFLAGS. This
On Tue, 26 Mar 2024 19:46:00 GMT, Phil Race 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 the
On Tue, 26 Mar 2024 23:01:55 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 145:
>>
>>> 143: -delayload:gdi32.dll -delayload:imm32.dll -delayload:ole32.dll
>>> \
>>> 144: -delayload:shell32.dll -delayload:shlwapi.dll
>>>
On Tue, 26 Mar 2024 19:25:47 GMT, Phil Race 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 the
On Tue, 26 Mar 2024 19:19:14 GMT, Phil Race 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 the
On Tue, 26 Mar 2024 21:44:12 GMT, Erik Joelsson 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.
>
>
On Tue, 26 Mar 2024 19:30:01 GMT, Magnus Ihse Bursie wrote:
> On AIX, we need a static libjli, since the linker cannot find other libraries
> (like libjvm.so and libjava.so) using a relative path, as on other platforms.
>
> However, for reasons unclear, we still build a dynamic libjli.so on
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.
Marked as
On Tue, 26 Mar 2024 08:44:31 GMT, Julian Waters wrote:
> Maybe as a further improvement, I can inline
> THROW_NULL_PDATA_IF_NOT_DESTROYED at its callsites and replace the bad
> NullPointerException error message with the proper null pointer name. Since
> Phil isn't here, what do you think?
On Wed, 20 Mar 2024 06:44:02 GMT, Julian Waters wrote:
>> Sorry, I don't see a BOOL error anywhere?
>
> 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
On Tue, 26 Mar 2024 13:00:41 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, 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 Tue, 26 Mar 2024 19:30:01 GMT, Magnus Ihse Bursie wrote:
> On AIX, we need a static libjli, since the linker cannot find other libraries
> (like libjvm.so and libjava.so) using a relative path, as on other platforms.
>
> However, for reasons unclear, we still build a dynamic libjli.so on
On AIX, we need a static libjli, since the linker cannot find other libraries
(like libjvm.so and libjava.so) using a relative path, as on other platforms.
However, for reasons unclear, we still build a dynamic libjli.so on AIX, even
though this is never used. Instead, we also build a static
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.
As with the
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.
-
Commit messages:
- 8329102: Clean up jdk.jpackage native
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 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 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
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 worse shape
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 Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
On Tue, 26 Mar 2024 09:19:19 GMT, Magnus Ihse Bursie wrote:
> The file building.{md,html} indicates the required minimum version of Xcode
> to use. When the required minimum version of Clang was updated to 13
> ([JDK-8325878](https://bugs.openjdk.org/browse/JDK-8325878)), the minimum
> Xcode
On Tue, 26 Mar 2024 09:19:19 GMT, Magnus Ihse Bursie wrote:
> The file building.{md,html} indicates the required minimum version of Xcode
> to use. When the required minimum version of Clang was updated to 13
> ([JDK-8325878](https://bugs.openjdk.org/browse/JDK-8325878)), the minimum
> Xcode
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the
AIX build into this failure :
/opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
gmake[3]: *** [lib/CoreLibraries.gmk:194:
The file building.{md,html} indicates the required minimum version of Xcode to
use. When the required minimum version of Clang was updated to 13
([JDK-8325878](https://bugs.openjdk.org/browse/JDK-8325878)), the minimum Xcode
version was not updated. It should now be Xcode 13.0, rather than 8.
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
> 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 07:44:22 GMT, Magnus Ihse Bursie wrote:
> > I have a concern since the null check bailout involves
> > THROW_NULL_PDATA_IF_NOT_DESTROYED, which is no longer accurate if we remove
> > the pData local.
>
> The name of the macro is not great, but it does not involve pData
> 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 Mon, 25 Mar 2024 20:19:04 GMT, Hamlin Li wrote:
> But anyway, it's a furture incremental solution after this pr, am I right? Or
> are we going to change direction?
I'm honestly not sure what is the right way forward. It seems we all agree that
this PR is not the end solution we want. So
On Mon, 25 Mar 2024 20:19:04 GMT, Hamlin Li wrote:
> It's not necessary to integrate libsleef build sysstem into jdk, we just need
> to integrate the final sources (generated by sleef cmake) into jdk. I have
> tested it, it works.
That is an interesting approach. It will raise the bar for
On Tue, 26 Mar 2024 00:13:09 GMT, Julian Waters wrote:
> I have a concern since the null check bailout involves
> THROW_NULL_PDATA_IF_NOT_DESTROYED, which is no longer accurate if we remove
> the pData local.
The name of the macro is not great, but it does not involve pData (the bad NPE
On Tue, 26 Mar 2024 00:17: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
47 matches
Mail list logo
