> Get JDK 24 underway.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains 16 commits:
- Correct release year.
- Merge branch 'master' into JDK-8330188
- Add symbol files current with JDK 23 build 24.
- Merge branch 'master'
On Wed, 17 Apr 2024 23:24:06 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 more
On Tue, May 28, 2024 at 9:09 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2024-05-07 06:04, Jiangli Zhou wrote:
>
> I did think I correctly changed every dynamic check that you had added
> to a compile-time check, so it bewilders me somewhat when you say that
> jvm.cfg is not
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
This pull request has now been integrate
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
On Tue, 28 May 2024 16:27:24 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
> 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
On Fri, 24 May 2024 16:36:32 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
On 2024-05-07 06:04, Jiangli Zhou wrote:
I did think I correctly changed every dynamic check that you had added
to a compile-time check, so it bewilders me somewhat when you say that
jvm.cfg is not needed in your branch.
Can you verify and confirm that the static launcher actually works in
your
On Fri, 24 May 2024 16:36:32 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
On Fri, 24 May 2024 16:36:32 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
On Sat, 25 May 2024 06:48:26 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
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
On Tue, 28 May 2024 02:41:42 GMT, David Holmes wrote:
> What testing has been done in our CI?
I have run tier-1.
And, as I said, I had also made the typical build change test: comparing the
build results bit-for-bit. On macOS and Windows, there were no differences. On
linux, there were a few
> 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
On Tue, 28 May 2024 02:39:01 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into hotspot-assembler-functions
>> - Fix copyright headers
16 matches
Mail list logo
