Re: RFR: 8330542: Template for Creating Strict JAXP Configuration File [v12]

2024-05-23 Thread Joe Wang
On Wed, 22 May 2024 08:52:42 GMT, Magnus Ihse Bursie wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add a note to module-info > > make/modules/java.xml/Copy.gmk line 35: > >> 33: $(eval $(call SetupCopyFiles, COPY_XM

Re: RFR: 8330542: Template for Creating Strict JAXP Configuration File [v13]

2024-05-23 Thread Joe Wang
On Fri, 24 May 2024 05:26:40 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 any

Re: RFR: 8330542: Template for Creating Strict JAXP Configuration File [v13]

2024-05-23 Thread Joe Wang
> 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 any more >> restricted configuration than previous versions

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

2024-05-23 Thread Iris Clark
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 Marked as reviewed by iris (Reviewer).

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

2024-05-23 Thread Mikael Vidstedt
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 - Commit messages: - 8332849: Update doc/testing.{md,html} (spelling and stale information) Ch

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

2024-05-23 Thread Ioi Lam
On Thu, 23 May 2024 20:28:49 GMT, Matias Saavedra Silva wrote: >> Ioi Lam 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 two additional commits

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

2024-05-23 Thread Matias Saavedra Silva
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` is

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

2024-05-23 Thread Alan Bateman
On Thu, 23 May 2024 16:42:39 GMT, Severin Gehwolf wrote: > Do you think you'll be able to review this next week? Yes, I want to help you get this one over the line. - PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2127828050

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

2024-05-23 Thread Coleen Phillimore
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 duplica

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

2024-05-23 Thread Severin Gehwolf
On Thu, 16 May 2024 13:47:20 GMT, Alan Bateman wrote: >>> If I understand you correctly, this would be no longer a build-time only >>> approach to produce the "linkable runtime"? It would be some-kind of >>> jlink-option driven approach (as it would run some code that should only >>> run when

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

2024-05-23 Thread Magnus Ihse Bursie
On Wed, 8 May 2024 13:30:59 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 duplicating t

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

2024-05-23 Thread Magnus Ihse Bursie
> 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 duplicating this code and create a unified macro to properly > setup func

Re: JDK-8170635 -- adding a base library to java

2024-05-23 Thread Magnus Ihse Bursie
On 2024-05-16 11:34, Suchismith Roy wrote: Hi Magnus Could you provide an existing PR/implementation I can refer from ? There is no such previous all-encompassing library to just "copy". In fact, the core problem here is that we are even missing such a place to put common code. This is not

Integrated: 8332808: Always set java.io.tmpdir to a suitable value in the build

2024-05-23 Thread Magnus Ihse Bursie
On Thu, 23 May 2024 10:27:47 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 regarding > [

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

2024-05-23 Thread Kevin Rushforth
On Thu, 23 May 2024 06:20:51 GMT, Alan Bateman wrote: > > Further, I confirm that if I pass that option to jlink or jpackage when > > creating a custom runtime, there is no warning. > > Great! What about jpackage without a custom runtime, wondering if > --java-options can be tested. Yes, poin

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

2024-05-23 Thread Erik Joelsson
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 regarding

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

2024-05-23 Thread Erik Joelsson
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` is

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

2024-05-23 Thread Magnus Ihse Bursie
> 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 regarding > [JDK-8331348](https://bugs.openjdk.org/browse/JDK-8331348). Ma

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

2024-05-23 Thread Magnus Ihse Bursie
On Thu, 23 May 2024 10:27:47 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 regarding > [

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

2024-05-23 Thread Magnus Ihse Bursie
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 regarding [JDK-8331348](https://bugs.openjdk.org/browse/JDK-8331348). -