> Add an .editorconfig to define indentation, trim trailing whitespace and open
> curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.
David Linus Briemann has updated the pull request incrementally with one
additional commit since the
On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann wrote:
>> Add an .editorconfig to define indentation, trim trailing whitespace and
>> open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated
On Tue, 11 Mar 2025 15:19:24 GMT, Matthias Baesken wrote:
> > Was this always redundant, and does removing it make no change to current
> > build options?
> > If so, great, let's remove the useless makefile lines.
>
> There was a bit of discussion before in the thread
> https://mail.openjdk.or
On Mon, 10 Mar 2025 23:37:39 GMT, Mikael Vidstedt wrote:
> Background (from JBS):
>
> graphviz is run during the build, and needs the build_platform variant rather
> than target_platform.
>
> Testing:
>
> tier1,builds-tier[2-5]
Thank you for the review!
-
PR Comment: https://gi
On Mon, 10 Mar 2025 23:37:39 GMT, Mikael Vidstedt wrote:
> Background (from JBS):
>
> graphviz is run during the build, and needs the build_platform variant rather
> than target_platform.
>
> Testing:
>
> tier1,builds-tier[2-5]
This pull request has now been integrated.
Changeset: da2b4f07
On Mon, 10 Mar 2025 23:37:39 GMT, Mikael Vidstedt wrote:
> Background (from JBS):
>
> graphviz is run during the build, and needs the build_platform variant rather
> than target_platform.
>
> Testing:
>
> tier1,builds-tier[2-5]
Marked as reviewed by erikj (Reviewer).
-
PR Revie
On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann wrote:
>> Add an .editorconfig to define indentation, trim trailing whitespace and
>> open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated
On Tue, 11 Mar 2025 13:18:55 GMT, Kevin Walls wrote:
> Windows fastdebug and release I just checked and saw -O1, I'm not sure why
> that is.
The change touches only Linux so Windows stays as it is.
> We do the same thing in make/modules/jdk.management/Lib.gmk so both these
> management locati
On Tue, 11 Mar 2025 11:54:29 GMT, Kevin Walls wrote:
> Is it worth making any change here?
This was needed because I removed
DISABLED_WARNINGS_gcc_VMManagementImpl.c
while changing the makefile.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989296776
On Tue, 11 Mar 2025 14:14:16 GMT, Matthias Baesken wrote:
>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
>> are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit sin
On Thu, 6 Mar 2025 10:39:27 GMT, snake66 wrote:
> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's
> possible to parameterize this for platforms that use different flags for
> enabling posix threads.
>
> This work is a continuation of the work done by Greg Lewis in
On Tue, 11 Mar 2025 15:04:58 GMT, Kevin Walls wrote:
> Remove a compiler directive to avoid unused var warnings, but change the code
> to make it imply a method has no return value when actually it returns a
> value: I think you could argue this either way, so I asked if it's really
> worthwhi
> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
> are most likely not needed any more and could be removed.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Bring back comment
-
Changes
On Mon, 10 Mar 2025 18:51:53 GMT, Matthias Baesken wrote:
>> make/modules/java.management/Lib.gmk line 33:
>>
>>> 31: ## Build libmanagement
>>> 32:
>>>
>>> 33:
>>
>> Why remove the comment header. This pattern i
On Tue, 11 Mar 2025 09:04:59 GMT, Matthias Baesken wrote:
>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
>> are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit sin
On Fri, 7 Mar 2025 07:18:27 GMT, David Holmes wrote:
> You could add a couple of lines to the build code and it would not be
> possible to build 32-bit, so that is a necessary but not sufficient condition
> to claim to implement the JEP IMO.
Agreed. This is why this PR removes the actual imple
On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro wrote:
>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that
>> it's possible to parameterize this for platforms that use different flags
>> for enabling posix threads.
>>
>> This work is a continuation of the work done by G
On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt wrote:
> Background (from JBS):
>
> Recent versions of Xcode, most likely starting with Xcode 15, do not produce
> deterministic binaries/libraries out of the box. In particular, the UUID data
> in the LC_UUID load command is not stable.
>
> Af
On Sat, 8 Mar 2025 13:39:44 GMT, snake66 wrote:
>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that
>> it's possible to parameterize this for platforms that use different flags
>> for enabling posix threads.
>>
>> This work is a continuation of the work done by Greg Lew
On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou wrote:
> Please review this PR that excludes `libjsig` from being statically linked
> with `static-jdk` `java` launcher by default. Please see details in
> https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks
IIUC, signal ch
On Mon, 10 Mar 2025 08:57:11 GMT, David Linus Briemann wrote:
> I guess the question is: are these guidelines obligatory and if so why can we
> not define this in an editorconfig?
No, they are not. That's kind of the crux of the problem.
* The Hotspot guidelines are followed to a great extent,
On Thu, 6 Mar 2025 13:27:15 GMT, snake66 wrote:
>> Abstracting this out seems reasonable to me, though I should say I thought
>> we already used `-pthread` rather than `-lpthread`.
>>
>> Needs build team approval before integrating.
>
>> Abstracting this out seems reasonable to me, though I sho
On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou wrote:
> Please review the test fix that removes `libVThreadEventTest` explicit
> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With
> the chang
On Fri, 7 Mar 2025 15:06:18 GMT, Magnus Ihse Bursie wrote:
>> I think leaving a comment describing how to deprecate a port is useful. To
>> look it up in history you have to realise there is something to look up.
>>
>> "They who are not reminded of the past will invent a new way to do it in the
Background (from JBS):
graphviz is run during the build, and needs the build_platform variant rather
than target_platform.
Testing:
tier1,builds-tier[2-5]
-
Commit messages:
- 8351606: Use build_platform for graphviz dependency
Changes: https://git.openjdk.org/jdk/pull/23976/fil
On Fri, 7 Mar 2025 20:46:32 GMT, Mikael Vidstedt wrote:
> Background (from JBS):
>
> Recent versions of Xcode, most likely starting with Xcode 15, do not produce
> deterministic binaries/libraries out of the box. In particular, the UUID data
> in the LC_UUID load command is not stable.
>
> Af
On Tue, 11 Mar 2025 09:04:59 GMT, Matthias Baesken wrote:
>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
>> are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit sin
On Tue, 11 Mar 2025 13:36:42 GMT, Matthias Baesken wrote:
>> src/java.management/share/native/libmanagement/VMManagementImpl.c line 63:
>>
>>> 61: {
>>> 62: jmmOptionalSupport mos;
>>> 63: jmm_interface->GetOptionalSupport(env, &mos);
>>
>> Is it worth making any change here?
>>
>> We
On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev wrote:
>> These resources files are in Java classes. If converted to properties files,
>> the localized versions can use UTF-8 encoding directly.
>>
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/sha
On 2025-03-10 13:02, Baesken, Matthias wrote:
Hello, while looking at the JDK native lib optimization levels, I
noticed this special setting :
make/modules/java.management/Lib.gmk
ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
LIBMANAGEMENT_OPTIMIZATION := LOW
end
> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
> are most likely not needed any more and could be removed.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust jdk.management/Lib.gmk
---
On Tue, 11 Mar 2025 15:04:58 GMT, Kevin Walls wrote:
> Was this always redundant, and does removing it make no change to current
> build options?
> If so, great, let's remove the useless makefile lines.
There was a bit of discussion before in the thread
https://mail.openjdk.org/pipermail/build
On Tue, 11 Mar 2025 14:14:16 GMT, Matthias Baesken wrote:
>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
>> are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit sin
> This PR implements JEP 503: Remove the 32-bit x86 Port.
>
> The JEP is proposed to target 25, we would not integrate until JEP is ready.
> Reviews are appreciated meanwhile.
>
> This is only the removal of obvious 32-bit x86 parts, mostly files with
> `x86_32` in their name. Those are only b
On Fri, 7 Mar 2025 09:22:44 GMT, Doug Simon wrote:
>>> It seems we agree that we need, at some point, to have a high-level
>>> discussion on if libjsig should be supported on static builds, and if so,
>>> how it should be implemented. We also agree that having signal chaining
>>> enabled by de
On Mon, 10 Mar 2025 11:03:06 GMT, Magnus Ihse Bursie wrote:
> With that confirmation, I think we should go on with the `ONLY_EXPORTED`
> solution instead.
Done. I also reverted StaticLibs.gmk change.
@caoman @tstuefe, please see if the updated change still looks okay to you.
>
> If needed, w
Allows for future support for platforms that require different flags for
libiconv support.
Sponsored-by: The FreeBSD Foundation
-
Commit messages:
- 8351323: Parameterize libiconv compiler and linker flags
Changes: https://git.openjdk.org/jdk/pull/23995/files
Webrev: https://web
Hi Magnus,
As mentioned before, the core idea here is really just providing a hook
for a script to be invoked after the native linker has been called.
So while thinking about making this more generic and not Windows
specific, it struck me that it might in fact be desirable to also drop
the "si
On Mon, 10 Mar 2025 18:28:44 GMT, Jiangli Zhou wrote:
>> Please review this PR that excludes `libjsig` from being statically linked
>> with `static-jdk` `java` launcher by default. Please see details in
>> https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks
>
> Jiangli
On Mon, 10 Mar 2025 18:39:46 GMT, Jiangli Zhou wrote:
> > With that confirmation, I think we should go on with the `ONLY_EXPORTED`
> > solution instead.
>
> Done. I also reverted StaticLibs.gmk change.
>
> @caoman @tstuefe, please see if the updated change still looks okay to you.
I also test
On Mon, 10 Mar 2025 11:03:06 GMT, Magnus Ihse Bursie wrote:
>> Please review this PR that excludes `libjsig` from being statically linked
>> with `static-jdk` `java` launcher by default. Please see details in
>> https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks
>
> Wi
On 2025-03-10 14:49, Baesken, Matthias wrote:
* I very much doubt it's needed, but it does mean that this lib has
been compiled at "LOW" for most, if not all, relevant builds of
OpenJDK since then.
**
If I create a PR removing this special handling, could you please test
it in your
On Mon, 16 Dec 2024 22:03:59 GMT, Artur Barashev wrote:
> These resources files are in Java classes. If converted to properties files,
> the localized versions can use UTF-8 encoding directly.
>
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/cl
On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes wrote:
>>> What is the intended way of using this? Do you run make with
>>> LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the
>>> specific way of linking to pthread?
>>
>> This is in preparation of the upcoming BSD port, which use
On Tue, 4 Mar 2025 23:52:49 GMT, Harshitha Onkar wrote:
> Harfbuzz upgraded to v10.4.0
>
> File changes -
>
> **Newly added files**
>
> libharfbuzz/OT/Var/VARC/VARC.hh
> libharfbuzz/OT/Var/VARC/coord-setter.hh
> libharfbuzz/hb-decycler.hh
> libharfbuzz/hb-geometry.hh
> libharfbuzz/hb-ot-var-v
On Mon, 10 Mar 2025 15:38:45 GMT, Matthias Baesken wrote:
> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
> are most likely not needed any more and could be removed.
While at it I also cleaned up some unused variable issue.
-
PR Comment: https://git.
On Thu, 6 Mar 2025 17:28:10 GMT, snake66 wrote:
>> make/autoconf/libraries.m4 line 142:
>>
>>> 140: # Threading library
>>> 141: if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS"
>>> = xaix; then
>>> 142: BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
>>
>> If you sp
On Mon, 10 Mar 2025 09:49:44 GMT, Aleksey Shipilev wrote:
>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>>
>> The JEP is proposed to target 25, we would not integrate until JEP is ready.
>> Reviews are appreciated meanwhile.
>>
>> This is only the removal of obvious 32-bit x86 par
On Tue, 11 Mar 2025 19:35:45 GMT, Erik Joelsson wrote:
>> Allows for future support for platforms that require different flags for
>> libiconv support.
>>
>> Sponsored-by: The FreeBSD Foundation
>
> I think this looks ok, but please wait for Magnus to have a look too.
@erikj79 Thanks for the r
On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev wrote:
>> These resources files are in Java classes. If converted to properties files,
>> the localized versions can use UTF-8 encoding directly.
>>
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/sha
On Tue, 11 Mar 2025 19:22:34 GMT, snake66 wrote:
> Allows for future support for platforms that require different flags for
> libiconv support.
>
> Sponsored-by: The FreeBSD Foundation
I think this looks ok, but please wait for Magnus to have a look too.
-
Marked as reviewed by e
On Thu, 5 Dec 2024 18:44:06 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request wit
Hello, while looking at the JDK native lib optimization levels, I noticed this
special setting :
make/modules/java.management/Lib.gmk
ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
LIBMANAGEMENT_OPTIMIZATION := LOW
endif
Why is it there ?
I removed it in out inter
> Add an .editorconfig to define indentation, trim trailing whitespace and open
> curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.
David Linus Briemann has updated the pull request incrementally with one
additional commit since the
* I very much doubt it's needed, but it does mean that this lib has been
compiled at "LOW" for most, if not all, relevant builds of OpenJDK since then.
If I create a PR removing this special handling, could you please test it in
your CI to be sure that nothing bad happens ?
Best regards,
On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that
are most likely not needed any more and could be removed.
-
Commit messages:
- JDK-8351542
Changes: https://git.openjdk.org/jdk/pull/23966/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23966&ran
56 matches
Mail list logo
