owing the version of the module shipped with JavaFX to be
> used in favor of the deprecated module in the JDK itself.
Kevin Rushforth 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 mer
On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote:
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
> with JavaFX instead.
>
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
> openjdk/jfx#1529 for the JavaFX PR that will inc
On Fri, 6 Sep 2024 01:52:10 GMT, Roger Riggs wrote:
> Looks good. I'll review the CSR when its ready.
Thanks.
> The changes to make jdk.jsobject an upgradeable module looks right.
Thanks for checking. My testing primarily focused on this aspect of the change,
so it's pretty well tested.
> I
On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote:
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
> with JavaFX instead.
>
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
> openjdk/jfx#1529 for the JavaFX PR that will inc
Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with
JavaFX instead.
See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX.
That PR describes the needed test scenarios.
This PR d
On Tue, 18 Jun 2024 22:50:15 GMT, Phil Race wrote:
> > @prrace Any objections to the current version of the warning message?
>
> Meaning this example " ⚠️ Patch contains a binary file (duke-thinking.png)"
Yeah, that one.
-
PR Comment: https://git.openjdk.org/jdk/pull/19683#issuec
On Thu, 13 Jun 2024 17:50:21 GMT, Phil Race wrote:
>> @kevinrushforth said in
>> [SKARA-2289](https://bugs.openjdk.org/browse/SKARA-2289), 'In general, our
>> repositories contain source code and not binary files. There are exceptions
>> to this for images and other similar resources, but othe
On Wed, 12 Jun 2024 22:38:37 GMT, Zhao Song wrote:
> @kevinrushforth said in
> [SKARA-2289](https://bugs.openjdk.org/browse/SKARA-2289), 'In general, our
> repositories contain source code and not binary files. There are exceptions
> to this for images and other similar resources, but otherwis
On Wed, 12 Jun 2024 22:38:37 GMT, Zhao Song wrote:
> @kevinrushforth said in
> [SKARA-2289](https://bugs.openjdk.org/browse/SKARA-2289), 'In general, our
> repositories contain source code and not binary files. There are exceptions
> to this for images and other similar resources, but otherwis
On Wed, 12 Jun 2024 22:38:37 GMT, Zhao Song wrote:
> @kevinrushforth said in
> [SKARA-2289](https://bugs.openjdk.org/browse/SKARA-2289), 'In general, our
> repositories contain source code and not binary files. There are exceptions
> to this for images and other similar resources, but otherwis
On Thu, 6 Jun 2024 18:24:50 GMT, Kevin Rushforth wrote:
> Clean backport of `.jcheck/conf` change to jdk23.
This pull request has now been integrated.
Changeset: 31696a44
Author: Kevin Rushforth
Committer: Iris Clark
URL:
https://git.openjdk.org/jdk/com
On Thu, 6 Jun 2024 19:38:44 GMT, Kevin Rushforth wrote:
> Test comment to check that Skara now prefixes the RFR email with the target
> branch (if not master).
It should work now.
-
PR Comment: https://git.openjdk.org/jdk/pull/19584#issuecomment-2153295983
On Thu, 6 Jun 2024 18:24:50 GMT, Kevin Rushforth wrote:
> Clean backport of `.jcheck/conf` change to jdk23.
Test comment to check that Skara now prefixes the RFR email with the target
branch (if not master).
-
PR Comment: https://git.openjdk.org/jdk/pull/19584#issuecomm
Clean backport of `.jcheck/conf` change to jdk23.
-
Commit messages:
- Backport 2a37764e7428d579a3080e62681f1c9c9f816c1e
Changes: https://git.openjdk.org/jdk/pull/19584/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19584&range=00
Issue: https://bugs.openjdk.org/browse/J
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 manu
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 time).
-
Commit messages:
- 8333743: Change .jcheck/con
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
On Fri, 17 May 2024 13:38:25 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 `Runtime::loa
On Tue, 21 Nov 2023 14:42:07 GMT, Kevin Rushforth wrote:
> At some point we are likely to use stabilization branches in the mainline jdk
> repo rather than a separate repo. In preparation, this PR excludes branches
> matching `jdk*`, like we currently do for `master` and `pr/*
On Tue, 21 Nov 2023 21:40:49 GMT, intrigus-lgtm wrote:
> May I ask, why you all are so fixated on using `branches-ignore:`? Can you
> not simply add another job, that ignore pushes if the branch name has a
> specific format and if the repository is "openjdk/jdk"?
I think you misunderstand how
On Tue, 21 Nov 2023 14:42:07 GMT, Kevin Rushforth wrote:
> At some point we are likely to use stabilization branches in the mainline jdk
> repo rather than a separate repo. In preparation, this PR excludes branches
> matching `jdk*`, like we currently do for `master` and `pr/*
On Tue, 21 Nov 2023 14:42:07 GMT, Kevin Rushforth wrote:
> At some point we are likely to use stabilization branches in the mainline jdk
> repo rather than a separate repo. In preparation, this PR excludes branches
> matching `jdk*`, like we currently do for `master` and `pr/*
On Tue, 21 Nov 2023 15:58:58 GMT, Kevin Rushforth wrote:
> However, that's an interesting point about it excluding a username that
> begins with `jdk` given how the bot creates the branch name for the
> `/backport` command.
I note that this would be easy to fix by changing
On Tue, 21 Nov 2023 14:42:07 GMT, Kevin Rushforth wrote:
> At some point we are likely to use stabilization branches in the mainline jdk
> repo rather than a separate repo. In preparation, this PR excludes branches
> matching `jdk*`, like we currently do for `master` and `pr/*
At some point we are likely to use stabilization branches in the mainline jdk
repo rather than a separate repo. In preparation, this PR excludes branches
matching `jdk*`, like we currently do for `master` and `pr/*`.
A potential drawback of doing this is that it will exclude developer branches
On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou wrote:
> 8307858: [REDO] JDK-8307194 Add make target for optionally building a
> complete set of all JDK and hotspot libjvm static libraries
Since this Enhancement was rejected for JDK 21, this PR should be closed.
-
PR Comment: https
On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou wrote:
> 8307858: [REDO] JDK-8307194 Add make target for optionally building a
> complete set of all JDK and hotspot libjvm static libraries
As a P4 enhancement, this doesn't meet the criteria for integration into JDK 21
during [Rampdown Phase
1]
On Sun, 15 Jan 2023 01:56:06 GMT, Jie Fu wrote:
>> src/java.desktop/share/native/libharfbuzz/hb-meta.hh line 191:
>>
>>> 189: #define hb_int_max(T) hb_int_max::value
>>> 190:
>>> 191: #if defined(__GNUC__) && __GNUC__ < 5 && !defined(__clang__)
>>
>> Normally, such changes in third-party libra
On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote:
> Hi all,
>
> Please review the fix for the build failure with clang-15.
>
> 1. -Wbitwise-instead-of-logical
>
>1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the
> warning
>2) src/hotspot/share/runtime/notificationThre
On Sat, 14 Jan 2023 14:28:32 GMT, Jie Fu wrote:
> Hi all,
>
> Please review the fix for the build failure with clang-15.
>
> 1. -Wbitwise-instead-of-logical
>
>1) src/hotspot/share/oops/generateOopMap.cpp <--- fixed the
> warning
>2) src/hotspot/share/runtime/notificationThre
30 matches
Mail list logo
