Re: RFR: 8334036: Update JCov for class file version 68

On Tue, 11 Jun 2024 19:02:29 GMT, Alexandre Iline wrote: > Update JCov for class file version 68 Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19665#pullrequestreview-2111324522

Re: RFR: 8333685: Make update-copyright-year script more useful [v2]

On Tue, 11 Jun 2024 13:34:24 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8333685](https://bugs.openjdk.org/browse/JDK-8333685). >> >> I have added the following enhancements: >> - Removed uses of `fgrep` and `egrep` with `grep -F` and `grep -E` >> respectively.

Re: RFR: 8333685: Make update-copyright-year script more useful

On Tue, 11 Jun 2024 12:32:59 GMT, Thomas Stuefe wrote: > Tested on Linux, there it works. > > Note, IIRC, the original unpatched version also worked on MacOS. So, I think > the original sed expressions were probably ok. Something about > `(${copyright_symbol} )?` perhabs. Mac has bsd sed by

Re: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]

On Fri, 7 Jun 2024 12:37:48 GMT, Julian Waters wrote: >> SendaoYan has updated the pull request incrementally with one additional >> commit since the last revision: >> >> delete extra empty trailing blank line in >> test/jdk/java/rmi/reliability/benchmark/bench/Makefile > >

Re: RFR: 8333477: Delete extra empty spaces in Makefiles [v2]

On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote: >> Hi all, >> This PR several extra empty spaces and extra empty lines in several >> Makefiles. It's trivial fix, no risk. >> >> Thanks. > > SendaoYan has updated the pull request incrementally with one additional > commit since the last

Re: [jdk23] RFR: 8333743: Change .jcheck/conf branches property to match valid branches

On Thu, 6 Jun 2024 18:24:50 GMT, Kevin Rushforth wrote: > Clean backport of `.jcheck/conf` change to jdk23. Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/19584#pullrequestreview-2103122924

Re: RFR: 8333743: Change .jcheck/conf branches property to match valid branches

On Thu, 6 Jun 2024 17:10:16 GMT, Kevin Rushforth wrote: > Update the `branches` property in `.jcheck/conf` to allow branches, now that > we are using them for JDK stabilization. This will allow integrators to use > Skara to create new stabilization branches (we had to do it manually this >

Re: Removing mercurial support for update-copyright-year script

I see no problem with removing Mercurial support. /Erik On 6/6/24 08:21, Sonia Zaldana Calles wrote: Adding @Thomas Stuefe  to the thread. On Thu, Jun 6, 2024 at 11:20 AM Sonia Zaldana Calles wrote: Hi folks, I'm working on JDK-8333685 [0]. I was

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v31]

On Wed, 5 Jun 2024 17:31:44 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8333477: Delete extra empty spaces in Makefiles

On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote: > Hi all, > This PR several extra empty spaces and extra empty lines in several > Makefiles. It's trivial fix, no risk. > > Thanks. Marked as reviewed by erikj (Reviewer). - PR Review:

Re: RFR: 8333301: Remove static builds using --enable-static-build

On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote: > The original way of building static libraries in the JDK was to use the > configure argument --enable-static-build, which set the value of the make > variable STATIC_BUILD. (Note that this is not the same as the source code >

Re: RFR: 8333282: Better warning if newly build JDK fails to run

On Thu, 30 May 2024 15:02:38 GMT, Magnus Ihse Bursie wrote: > If the newly built JDK fails to run ("DOA"), we will get a strange error > message about jdk.compiler-gendata errors from make. The reason is not at all > obvious. > > Instead, we should make a simple check that we can actually use

Re: RFR: 8333189: Make sure clang on linux uses lld as linker

On Wed, 29 May 2024 15:01:27 GMT, Magnus Ihse Bursie wrote: > When compiling with clang on linux, clang can decide to pick up the bfd > linker instead of lld, the LLVM linker. This will invalidate assumptions > about command lines that are passed on to the linker. We should use > -fuse-ld=lld

Re: RFR: 8332849: Update doc/testing.{md,html} (spelling and stale information) [v2]

On Fri, 24 May 2024 21:05:27 GMT, Mikael Vidstedt wrote: >> Update the testing doc to remove some stale information (AOT_MODULES, >> removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805)) and >> fix some spelling issues. >> >> Testing: tier1 > > Mikael Vidstedt has updated the

Re: RFR: 8332885: Clarify failure_handler self-tests

On Fri, 24 May 2024 12:16:25 GMT, Ludvig Janiuk wrote: > Adding commetns to clarify that the failure_handler selftests are intended to > be run manually. Ideally this would include a more thorough description of > the exepcted outputs, but this is what I have time to add right now.

Re: RFR: 8332849: Update doc/testing.{md,html} (spelling and stale information)

On Thu, 23 May 2024 23:22:51 GMT, Mikael Vidstedt wrote: > Update the testing doc to remove some stale information (AOT_MODULES, removed > in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805)) and fix some > spelling issues. > > Testing: tier1 Changes requested by erikj (Reviewer).

Re: RFR: 8332849: Update doc/testing.{md,html} (spelling and stale information)

On Fri, 24 May 2024 09:15:51 GMT, Daniel Jeliński wrote: >> Update the testing doc to remove some stale information (AOT_MODULES, >> removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805)) and >> fix some spelling issues. >> >> Testing: tier1 > > doc/testing.html line 366: >

Re: RFR: 8331921: Hotspot assembler files should use common logic to setup exported functions [v2]

On Thu, 23 May 2024 16:33:14 GMT, Magnus Ihse Bursie wrote: >> As seen in [JDK-8331541](https://bugs.openjdk.org/browse/JDK-8331541), if we >> are not consistently setting all assembler directives correctly, we can get >> errors that are not detected by the linker. >> >> We should stop

Re: RFR: 8332808: Always set java.io.tmpdir to a suitable value in the build [v2]

On Thu, 23 May 2024 11:39:18 GMT, Magnus Ihse Bursie wrote: >> We should pass a good value for java.io.tmpdir to all java invocations in >> the build, that redirect any temporary files to somewhere under the build >> directory. >> >> This bug was created as a result of the discussion

Re: RFR: 8293980: Resolve CONSTANT_FieldRef at CDS dump time [v2]

On Thu, 23 May 2024 03:35:19 GMT, Ioi Lam wrote: >> ### Overview >> >> This PR archives `CONSTANT_FieldRef` entries in the _resolved_ state when >> it's safe to do so. >> >> I.e., when a `CONSTANT_FieldRef` constant pool entry in class `A` refers to >> a *non-static* field `B.F`, >> - `B`

Re: RFR: 8332545: Fix handling of HTML5 entities in Markdown comments

On Mon, 20 May 2024 20:17:10 GMT, Jonathan Gibbons wrote: > Please review a small fix to address a crash when handling HTML5 entities in > a Markdown doc comment. > > The path for the `entities.txt` (originally `entities.properties`) was not > correctly imported when importing the latest

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v9]

On Fri, 17 May 2024 21:57:00 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]

On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]

On Fri, 17 May 2024 05:51:31 GMT, Alan Bateman wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> remove jaxp-compat.properties from the list > > make/modules/java.xml/Copy.gmk line 37: > >> 35:

Re: RFR: 8329816: Add SLEEF version 3.6

On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote: > [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to > optimize vector math operations by leveraging the SLEEF library. For legal > reasons the actual contribution of the SLEEF files needs to be handled >

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]

On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and

Re: RFR: 8332096: hotspot-ide-project fails with this-escape

On Fri, 10 May 2024 23:54:11 GMT, Alex Menkov wrote: > The change fixes `make hotspot-ide-project` which fails with > > \open\make\ide\visualstudio\hotspot\src\classes\build\tools\projectcreator\FileTreeCreator.java:54: > warning: [this-escape] possible 'this' escape before subclass is fully

Re: RFR: 8332085: Remove 10 year old transition check in GenerateCurrencyData tool

On Fri, 10 May 2024 21:30:21 GMT, Naoto Sato wrote: > The build tool that generates the currency data had a check that throws an > exception (causes a build failure) if the transition date is more than 10 > years away (past/future). This caused a build failure in 8u-RI repository. > Since the

Re: RFR: 8332008: Enable issuestitle check

On Thu, 9 May 2024 20:53:59 GMT, Zhao Song wrote: > As requested in [SKARA-2170](https://bugs.openjdk.org/browse/SKARA-2170) and > [SKARA-2248](https://bugs.openjdk.org/browse/SKARA-2248), now Skara bot is > able to warn on trailing periods or leading lowercase letter in issue titles. > I am

Re: RFR: 8331952: --enable-compatible-cds-alignment should be enabled by default

On Thu, 9 May 2024 01:07:26 GMT, xiaotaonan wrote: > --enable-compatible-cds-alignment should be enabled by default Build change looks ok. I think this should be approved by someone from hotspot as well. - Marked as reviewed by erikj (Reviewer). PR Review:

Integrated: 8331939: Add custom hook for TestImage

On Wed, 8 May 2024 14:03:48 GMT, Erik Joelsson wrote: > We need a custom hook in TestImage.gmk to modify behavior when building with > custom source. This pull request has now been integrated. Changeset: 0d1216c7 Author: Erik Joelsson URL: https://git.openjdk.org/jdk/

Integrated: 8331886: Allow markdown src file overrides

On Wed, 8 May 2024 01:02:41 GMT, Erik Joelsson wrote: > For c, c++ and java source files, we have a built in system for letting more > specific files override if there are multiple files with the same name found, > by letting the first found file with a given name override any la

Re: RFR: 8331886: Allow markdown src file overrides [v2]

ProcessMarkdown.gmk is more or less copied from > SetupNativeCompilation. Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits

RFR: 8331939: Add custom hook for TestImage

We need a custom hook in TestImage.gmk to modify behavior when building with custom source. - Commit messages: - JDK-8331939 Changes: https://git.openjdk.org/jdk/pull/19139/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19139=00 Issue:

RFR: 8331886: Allow markdown src file overrides

For c, c++ and java source files, we have a built in system for letting more specific files override if there are multiple files with the same name found, by letting the first found file with a given name override any later found files with that name. This is typically used for OS specific

Re: [External] : RE: JDK-8170635

On 5/7/24 01:04, Suchismith Roy wrote: Hi Thomas Thank you for the reply. I want to reach out to Erik who was working on this issue. @erik.joels...@oracle.com Do you also propose the same solution as mentioned by Thomas ? This is an almost 8 year old email

Re: How do I reliably prevent CDS archive generation during builds?

On 5/6/24 09:26, Thomas Stüfe wrote: Hi, is there a way to reliably prevent the jvm from being called with -Xshare:dump during build? Often, when I tinker with metaspace or compressed klass pointers, CDS gets broken. During development, that is fine; it is a temporary state. However, if

Re: RFR: 8331331: :tier1 target explanation in doc/testing.md is incorrect [v2]

On Wed, 1 May 2024 14:46:14 GMT, SendaoYan wrote: >> Hi, >> >> In doc/testing.md file, it says: >> >> As an example, :tier1 will expand to >> jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1 jtreg:$(TOPDIR)/test/jdk:tier1 >> jtreg:$(TOPDIR)/test/langtools:tier1 jtreg:$(TOPDIR)/test/nashorn:tier1 >>

Re: RFR: 8331331: :tier1 target explanation in doc/testing.md is incorrect

On Mon, 29 Apr 2024 16:14:45 GMT, SendaoYan wrote: > Hi, > > In doc/testing.md file, it says: > > As an example, :tier1 will expand to jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1 > jtreg:$(TOPDIR)/test/jdk:tier1 jtreg:$(TOPDIR)/test/langtools:tier1 > jtreg:$(TOPDIR)/test/nashorn:tier1

Re: RFR: 8331331: :tier1 target explanation in doc/testing.md is incorrect

On Mon, 29 Apr 2024 16:14:45 GMT, SendaoYan wrote: > Hi, > > In doc/testing.md file, it says: > > As an example, :tier1 will expand to jtreg:$(TOPDIR)/test/hotspot/jtreg:tier1 > jtreg:$(TOPDIR)/test/jdk:tier1 jtreg:$(TOPDIR)/test/langtools:tier1 > jtreg:$(TOPDIR)/test/nashorn:tier1

Re: RFR: 8331298: avoid alignment checks in UBSAN enabled build

On Mon, 29 Apr 2024 12:15:55 GMT, Matthias Baesken wrote: > Currently we run into some alignment related issues when building with > '--enable-ubsan' . Those errors already occur in the build. Fixing them might > take some time and maybe also some discussion if it is worth the effort , > So

Re: RFR: 8331164: createJMHBundle.sh download jars fail when url needed to be redirected

On Fri, 26 Apr 2024 11:30:24 GMT, Jaikiran Pai wrote: > Adding `-L` (follow redirects) to unconditionally follow redirects doesn't > look right to me. I think, one would want to know, during the build process, > if any URLs that are in use (like this one) have changed their location and >

Re: RFR: 8331164: createJMHBundle.sh download jars fail when url needed to be redirected

On Fri, 26 Apr 2024 03:32:25 GMT, SendaoYan wrote: > Hi, > > The curl command lack of "-L" option, cause download file fail, the size of > download file is empty. > > curl download fail without `-L`: >```log >> rm -rf jmh-core-1.37.jar ; curl -O --fail >>

Re: RFR: 8331113: createJMHBundle.sh support configurable maven repo mirror

On Thu, 25 Apr 2024 09:47:11 GMT, SendaoYan wrote: > The script make/devkit/createJMHBundle.sh use fixed maven repo server: > https://repo.maven.apache.org/maven2. It's maybe useful to make the maven > repo mirror configurable. > > Only change devkit shell script, no risk. Marked as reviewed

Re: RFR: 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk [v3]

On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie wrote: >> The file to build most of the java.desktop native libraries, >> Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate. >> >> I want to split it into two parts, one for the AWT libraries, and one for >> the 2D

Integrated: 8329970: Update autoconf build-aux files with latest from 2024-01-01

On Tue, 9 Apr 2024 19:43:27 GMT, Erik Joelsson wrote: > Since we are now able to update the autoconf build-aux files, I think it's > prudent to semi regularly do just that. I'm not aware of any particular > platform that has been improved that would affect OpenJDK and I don't think

Re: RFR: 8330351: Remove the SHARED_LIBRARY and STATIC_LIBRARY macros

On Tue, 16 Apr 2024 09:31:19 GMT, Magnus Ihse Bursie wrote: > The macros SHARED_LIBRARY and STATIC_LIBRARY are weird (they do not fit in > with naming and placement of other macros), and almost never used. We should > just get rid of them. Marked as reviewed by erikj (Reviewer).

Re: RFR: 8330261: Clean up linking steps [v5]

On Tue, 16 Apr 2024 09:49:11 GMT, Magnus Ihse Bursie wrote: >> Instead of executing code directly in Link.gmk, we set variables that are >> then evaluated to get the code we want. This is non-transparent and makes it >> unnecessarily hard to work with the linking code base. >> >> This PR

Re: RFR: 8330261: Clean up linking steps [v3]

On Mon, 15 Apr 2024 13:43:53 GMT, Magnus Ihse Bursie wrote: >> Instead of executing code directly in Link.gmk, we set variables that are >> then evaluated to get the code we want. This is non-transparent and makes it >> unnecessarily hard to work with the linking code base. >> >> This PR

Re: RFR: 8330261: Clean up linking steps

On Mon, 15 Apr 2024 12:34:53 GMT, Magnus Ihse Bursie wrote: > Instead of executing code directly in Link.gmk, we set variables that are > then evaluated to get the code we want. This is non-transparent and makes it > unnecessarily hard to work with the linking code base. > > This PR also

Re: RFR: 8326947: Minimize MakeBase.gmk [v6]

On Thu, 11 Apr 2024 12:48:01 GMT, Magnus Ihse Bursie wrote: >> This is part of a general "spring cleaning" of the build system, addressing >> old code that has bit-rotted, been subject to lava flow, or just had bad or >> smelly code that we've never gotten around to fix. >> >> This particular

Re: RFR: 8329704: Implement framework for proper handling of JDK_LIBS [v7]

On Wed, 10 Apr 2024 14:43:26 GMT, Magnus Ihse Bursie wrote: >> This is the pinnacle of the recent stream of refactorings in the build >> system. This patch introduces a more abstract concept of "JDK_LIBS", where >> only the library name (e.g. "java" or "java.desktop:jawt") is specified, and

Re: RFR: 8329704: Implement framework for proper handling of JDK_LIBS [v2]

On Wed, 10 Apr 2024 13:41:53 GMT, Magnus Ihse Bursie wrote: >> make/common/JdkNativeCompilation.gmk line 206: >> >>> 204: $$(eval $$(call ResolveLibPath,$1,$2)) >>> 205: >>> 206: $1_EXTRA_HEADER_DIRS += $$($1_$2_MODULE):lib$$($1_$2_NAME) >> >> I think the top level comment need to be

Re: RFR: 8201183: sjavac build failures: "Connection attempt failed: Connection refused"

On Wed, 10 Apr 2024 11:32:43 GMT, Daniel Jeliński wrote: > The "Connection attempt failed: Connection refused" error may happen if the > client tries to connect to a server that is no longer listening, which in > turn may happen if the server shuts down without removing the port file. I >

RFR: 8329970: Update autoconf build-aux files with latest from 2024-01-01

Since we are now able to update the autoconf build-aux files, I think it's prudent to semi regularly do just that. I'm not aware of any particular platform that has been improved that would affect OpenJDK and I don't think we can further trim down our wrappers this time. This is more about

Re: RFR: 8324673: javacserver failed during build: RejectedExecutionException

On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeliński wrote: > The RejectedExecutionException was thrown when the thread executing > `Server.start` managed to shut down the `compilerThreadPool` before the > thread executing `Server.handleRequest` submitted the compilation task. > > This patch

Re: RFR: 8324673: javacserver failed during build: RejectedExecutionException

On Mon, 8 Apr 2024 14:27:28 GMT, Daniel Jeliński wrote: > It won't be a problem. The client side does not set timeout on socket > read/write operations, so there's no risk of the operation timing out. Also, > the OS usually buffers reads and writes, so the client write call probably > won't

Re: RFR: 8324673: javacserver failed during build: RejectedExecutionException

On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeliński wrote: > The RejectedExecutionException was thrown when the thread executing > `Server.start` managed to shut down the `compilerThreadPool` before the > thread executing `Server.handleRequest` submitted the compilation task. > > This patch

Re: RFR: 8329704: Implement framework for proper handling of JDK_LIBS

On Fri, 5 Apr 2024 10:11:02 GMT, Magnus Ihse Bursie wrote: > The syntax for specifying JDK libraries can of course be discussed. I tried > to align it with the current syntax for specifying source code, but it does > not match 100%. The differences are: > > * For source code, the default

Re: RFR: 8329704: Implement framework for proper handling of JDK_LIBS [v2]

On Fri, 5 Apr 2024 14:14:35 GMT, Magnus Ihse Bursie wrote: >> This is the pinnacle of the recent stream of refactorings in the build >> system. This patch introduces a more abstract concept of "JDK_LIBS", where >> only the library name (e.g. "java" or "java.desktop:jawt") is specified, and >>

Re: RFR: 8329672: Only call SetupNativeCompilation from SetupJdkNativeCompilation [v2]

On Thu, 4 Apr 2024 20:50:25 GMT, Magnus Ihse Bursie wrote: >> This patch will fix the few remaining places where a "raw" call to >> SetupNativeCompilation was made, instead of going via >> SetupJdkNativeCompilation. This include repairing the poor old X11Wrapper, >> which has been broken for

Re: RFR: 8329672: Only call SetupNativeCompilation from SetupJdkNativeCompilation

On Thu, 4 Apr 2024 16:02:53 GMT, Magnus Ihse Bursie wrote: > This patch will fix the few remaining places where a "raw" call to > SetupNativeCompilation was made, instead of going via > SetupJdkNativeCompilation. This include repairing the poor old X11Wrapper, > which has been broken for some

Re: RFR: 8329672: Only call SetupNativeCompilation from SetupJdkNativeCompilation

On Thu, 4 Apr 2024 16:02:53 GMT, Magnus Ihse Bursie wrote: > This patch will fix the few remaining places where a "raw" call to > SetupNativeCompilation was made, instead of going via > SetupJdkNativeCompilation. This include repairing the poor old X11Wrapper, > which has been broken for some

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v24]

On Thu, 4 Apr 2024 15:24:53 GMT, Severin Gehwolf wrote: >> make/CompileToolsJdk.gmk line 50: >> >>> 48: EXCLUDES := \ >>> 49: build/tools/classlist \ >>> 50: build/tools/runtimeimagelinkdeltaproducer \ >> >> This directory name is comically long. I guess that's not really a

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v24]

On Thu, 4 Apr 2024 11:12:43 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8320799: Bump minimum boot jdk to JDK 22

On Mon, 1 Apr 2024 16:16:50 GMT, Mikael Vidstedt wrote: > With the JDK 22 GA out it's time to bump the minimum boot JDK version for > mainline/JDK 23. > > Testing: tier1-5, GHA Marked as reviewed by erikj (Reviewer). - PR Review:

Re: RFR: 8329289: Unify SetupJdkExecutable and SetupJdkLibrary

On Thu, 28 Mar 2024 17:59:10 GMT, Magnus Ihse Bursie wrote: > Currently a lot of code is duplicated between SetupJdkExecutable and > SetupJdkLibrary. Furthermore, some functionality is still missing from > SetupJdkExecutable that is present in SetupJdkLibrary. These functions also > have not

Re: RFR: 8329292: Fix missing cleanups in java.management and jdk.management

On Thu, 28 Mar 2024 18:22:27 GMT, Magnus Ihse Bursie wrote: > For some reason, I missed adding the new standard header for SetupJdkLibrary > in java.management and jdk.management. I also missed to remove a now > superfluous CFLAGS_JDKLIB in libmanagement_ext. Marked as reviewed by erikj

Re: RFR: 8329289: Unify SetupJdkExecutable and SetupJdkLibrary

On Thu, 28 Mar 2024 17:59:10 GMT, Magnus Ihse Bursie wrote: > Currently a lot of code is duplicated between SetupJdkExecutable and > SetupJdkLibrary. Furthermore, some functionality is still missing from > SetupJdkExecutable that is present in SetupJdkLibrary. These functions also > have not

Re: RFR: 8329178: Clean up jdk.accessibility native compilation [v2]

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

Re: RFR: 8329178: Clean up jdk.accessibility native compilation [v2]

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. > >

Re: RFR: 8329178: Clean up jdk.accessibility native compilation

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.

Re: RFR: 8329086: Clean up java.desktop native compilation [v3]

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

Re: RFR: 8329086: Clean up java.desktop native compilation

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

Re: RFR: 8329086: Clean up java.desktop native compilation

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

Re: RFR: 8329086: Clean up java.desktop native compilation

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

Re: RFR: 8329131: Fold libjli_static back into libjli on AIX

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

Re: RFR: 8329102: Clean up jdk.jpackage native compilation

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

Re: RFR: 8328824: Clean up java.base native compilation

On Fri, 22 Mar 2024 17:09:16 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.base. Some code needed more special treatment here, > so there is some additional effects outside of the

Re: RFR: 8328680: Introduce JDK_LIB, and clean up module native compilation [v2]

On Fri, 22 Mar 2024 10:16:44 GMT, Magnus Ihse Bursie wrote: >> This is the first step of several, in which I will clean up the native >> compilation code as used by modules. In this first step `java.base`, >> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since >> they

Re: RFR: 8326960: GHA: RISC-V sysroot cannot be debootstrapped due to ongoing Debian t64 transition

On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote: > Debian "unstable" is currently undergoing t64 (hello, Y2038) transition, > which breaks "sid" repo that we use for debootstrapping RISC-V very often. > This is seen across multiple repositories, and requires everyone to look >

Re: RFR: 8328705: GHA: Cross-compilation jobs do not require build JDK

On Thu, 21 Mar 2024 16:57:40 GMT, Aleksey Shipilev wrote: > Noticed this while fixing other GHA issues. > > We pass build JDK to cross-compilation jobs, which makes them dependent on > Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS > there is no need for build JDK,

Re: RFR: 8328680: Introduce JDK_LIB, and clean up module native compilation

On Thu, 21 Mar 2024 11:49:11 GMT, Magnus Ihse Bursie wrote: > This is the first step of several, in which I will clean up the native > compilation code as used by modules. In this first step `java.base`, > `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since > they

Re: RFR: 8328628: JDK-8328157 incorrectly sets -MT on all compilers in jdk.jpackage

On Wed, 20 Mar 2024 16:20:36 GMT, Magnus Ihse Bursie wrote: > In [JDK-8328157](https://bugs.openjdk.org/browse/JDK-8328157), I rewrote the > logic to replace -MD with -MT for compiling on Windows. Unfortunately, I > mistakenly set -MT for all compilers, not just for visual studio. Marked as

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v20]

On Mon, 18 Mar 2024 18:40:36 GMT, Severin Gehwolf wrote: > What I mean to convey is that how the directory tree in `images/jdk` looks > like shouldn't change based on the `--enable-linkable-runtime-image` > configure flag. That is, there will be a `images/jdk/jmods` folder unless >

Re: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]

On Sat, 16 Mar 2024 22:20:53 GMT, Julian Waters wrote: >> Eclipse Shared Workspaces share the same directory as the JDK itself, which >> does not make much sense since there can be multiple different >> configurations of the JDK which Eclipse does depend on (as minimalistic as >> it is), and

Re: RFR: 8328177: Move LDFLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk

On Mon, 18 Mar 2024 09:16:12 GMT, Magnus Ihse Bursie wrote: > Similar to [JDK-8328157](https://bugs.openjdk.org/browse/JDK-8328157), we > want to move the setting of LDFLAGS to LDFLAGS_JDK[LIB/EXE into > SetupJdkLibrary and SetupJdkExecutable. Marked as reviewed by erikj (Reviewer).

Re: How to disable warnings treated as errors during the JDK build?

The configure flag --disable-warnings-as-errors only applies to native compilation, where the C/C++ compiler is used. For Java compilation, most of the source code is built using the interim javac, which is itself built from the JDK src, so we have full control over what warnings should or

Re: RFR: 8326964: Remove Eclipse Shared Workspaces [v4]

On Fri, 15 Mar 2024 13:17:24 GMT, Julian Waters wrote: >> Eclipse Shared Workspaces share the same directory as the JDK itself, which >> does not make much sense since there can be multiple different >> configurations of the JDK which Eclipse does depend on (as minimalistic as >> it is), and

Re: RFR: 8328157: Move C[XX]FLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk [v6]

On Fri, 15 Mar 2024 12:44:49 GMT, Magnus Ihse Bursie wrote: >> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`, >> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, >> respectively, in basically all calls to `SetupJdkLibrary` and >> `SetupJdkExecutable`. >>

Re: RFR: 8326964: Remove Eclipse Shared Workspaces [v3]

On Fri, 15 Mar 2024 07:15:55 GMT, Julian Waters wrote: >> Eclipse Shared Workspaces share the same directory as the JDK itself, which >> does not make much sense since there can be multiple different >> configurations of the JDK which Eclipse does depend on (as minimalistic as >> it is), and

Re: RFR: 8328146: Set LIBCXX automatically [v3]

On Thu, 14 Mar 2024 14:03:07 GMT, Magnus Ihse Bursie wrote: >> We are adding LIBCXX to LIBS in calls to SetupJdkLibrary whenever LINK_TYPE >> is C++. We should do this automatically in SetupJdkLibrary for C++ linking. >> >> I also removed the superfluous `-lc` from some places where it had

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v20]

On Thu, 14 Mar 2024 20:54:32 GMT, Mandy Chung wrote: > About the configure options, > > ``` > --enable-keep-packaged-modules > enable keeping of packaged modules in jdk image > [enabled] > --enable-runtime-link-image > enable producing an

Re: RFR: 8328157: Move C[XX]FLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk [v3]

On Thu, 14 Mar 2024 15:16:53 GMT, Magnus Ihse Bursie wrote: >> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`, >> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, >> respectively, in basically all calls to `SetupJdkLibrary` and >> `SetupJdkExecutable`. >>

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v20]

On Thu, 14 Mar 2024 14:24:57 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v20]

On Thu, 14 Mar 2024 14:27:47 GMT, Severin Gehwolf wrote: >> Severin Gehwolf has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix comment in autoconf file > > make/Images.gmk line 33: > >> 31: include Modules.gmk >> 32: include Utils.gmk

Re: RFR: 8328146: Set LIBCXX automatically [v3]

On Thu, 14 Mar 2024 14:03:07 GMT, Magnus Ihse Bursie wrote: >> We are adding LIBCXX to LIBS in calls to SetupJdkLibrary whenever LINK_TYPE >> is C++. We should do this automatically in SetupJdkLibrary for C++ linking. >> >> I also removed the superfluous `-lc` from some places where it had

Re: RFR: 8325621: Improve jspawnhelper version checks [v4]

On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy wrote: >> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621) >> >> Updates jspawnhelper to check that JDK version and jspawnhelper version are >> the same. Updates test to include check for version. Also tested manually by >>

Re: RFR: 8328106: COMPARE_BUILD improvements

On Wed, 13 Mar 2024 15:48:15 GMT, Magnus Ihse Bursie wrote: > This is a collection of various improvements to `COMPARE_BUILD` I have been > using lately. > > * Introducing `DEBUG_CDS_ARCHIVE` make variable, which is set automatically > when using `COMPARE_BUILD`. This will create a detailed

Re: RFR: 8328079: JDK-8326583 broke ccache compilation

On Wed, 13 Mar 2024 12:50:17 GMT, Magnus Ihse Bursie wrote: > According to > https://github.com/openjdk/jdk/pull/17986#issuecomment-1975396416, > [JDK-8326583](https://bugs.openjdk.org/browse/JDK-8326583) broke ccache > compilation. > > The reason was that the ccache command line included >

  1   2   3   4   5   6   7   8   9   >