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 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/*
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 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 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
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, 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
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 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
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.
This pull request has now been integrated.
Changeset: 31696a44
Author: Kevin Rushforth
Committer: Iris Clark
URL:
https://git.openjdk.org/jdk/com
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, 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 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
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 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 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
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 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 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
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 me
On Mon, 23 Sep 2024 16:32:23 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 J
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 merge/rebas
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 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
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 Tue, 3 Jun 2025 11:10:30 GMT, Nizar Benalla wrote:
> I have problemlisted
> `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is
> failing due to the symbol information lagging behind.
What is your plan for addressing this? In its current state, that problem list
entry w
On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote:
>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 20 commits:
>
> - Merge branch 'master' into jdk.8355746
> - Problemlist JavaBaseChec
On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla wrote:
>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 20 commits:
>
> - Merge branch 'master' into jdk.8355746
> - Problemlist JavaBaseChec
On Wed, 23 Jul 2025 15:22:04 GMT, Hannes Wallnöfer wrote:
>> The list is used as list of external linkable modules/packages for the
>> `-linkoffline` option. Since the list is for JDK 17 the entry could be left
>> in the list, but as the test doesn't try to link to the module removing it
>> do
On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth wrote:
> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK.
> This module is now shipped with JavaFX, and has been since JavaFX 24.
>
> The following files still reference `jdk.jsobj
On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth wrote:
> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK.
> This module is now shipped with JavaFX, and has been since JavaFX 24.
>
> The following files still reference `jdk.jsobj
This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK.
This module is now shipped with JavaFX, and has been since JavaFX 24.
The following files still reference `jdk.jsobject` (or the
`netscape.javascript` package). They are not modified because these files
reflect the st
On Tue, 22 Jul 2025 15:06:49 GMT, Alan Bateman wrote:
> I did a quick scan and the updates to the conf, the removal, and the test
> changes look okay. Happy to review the CSR when you have it ready.
Thanks. The CSR is now ready to review:
https://bugs.openjdk.org/browse/JDK-8362628
--
On Tue, 22 Jul 2025 15:13:44 GMT, Roger Riggs wrote:
>> This PR removes the terminally-deprecated `jdk.jsobject` module from the
>> JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>>
>> The following files still reference `jdk.jsobject` (or the
>> `netscape.javascrip
On Tue, 22 Jul 2025 18:48:59 GMT, Roger Riggs wrote:
>> I wondered about that, and originally was going to remove it, but then
>> noticed that the test in question parses the JDK 17 API docs (which does
>> have the `jdk.jsobject` module).
>>
>> https://github.com/openjdk/jdk/blob/e70c702d6f864
>
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX
> WebView.
Kevin Rushforth has updated the pull request incrementally with one additional
commit since the last revision:
Remove jdk.jsobject from one more test
-
Changes:
- all: https://
45 matches
Mail list logo
