I agree that we should separate the question of what to do today from
what our policy should be for future updates. As has been mentioned by
several folks, JDK 17 today is the obvious choice.
Btw, a couple people pointed out to me that we should really use
'--release 17' instead of '--source 1
On Tue, 19 Jul 2022 22:08:19 GMT, Andy Goryachev wrote:
> …ontract
>
> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect
> statement "Is functionally equivalent to calling
> getSelectedIndices().contains(index)."
> 2. reimplement TableView.isSelected(int) method to return t
On Tue, 19 Jul 2022 22:14:51 GMT, Kevin Rushforth wrote:
> Merge `jfx19` into `master`.
This pull request has now been integrated.
Changeset: 146dfeb8
Author:Kevin Rushforth
URL:
https://git.openjdk.org/jfx/commit/146dfeb89213d74d469766708f14690e0ed435dc
Stats: 41 lines in 5 fil
On Tue, 19 Jul 2022 22:08:19 GMT, Andy Goryachev wrote:
> …ontract
>
> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect
> statement "Is functionally equivalent to calling
> getSelectedIndices().contains(index)."
> 2. reimplement TableView.isSelected(int) method to return t
On Tue, 19 Jul 2022 22:08:19 GMT, Andy Goryachev wrote:
> …ontract
>
> 1. reword SelectionModel.isSelected(int) javadoc, removing incorrect
> statement "Is functionally equivalent to calling
> getSelectedIndices().contains(index)."
> 2. reimplement TableView.isSelected(int) method to return t
Merge `jfx19` into `master`.
-
Commit messages:
- Merge jfx19
- Merge
- Merge
- Merge
- Merge
- 8285691: Additional fix for JDK-8282121
- Merge
- 8282121: Improve WebKit referencing
The merge commit only contains trivial merges, so no merge-specific webrevs
have been generat
…ontract
1. reword SelectionModel.isSelected(int) javadoc, removing incorrect statement
"Is functionally equivalent to calling
getSelectedIndices().contains(index)."
2. reimplement TableView.isSelected(int) method to return true when at least
one cell in *any* column is selected on the given r
(I am not subbed so this might not arrive on the list but its cc'ed)
consider using -release instead of source/target if possible. This is
safer since it will actually compile against bytecode of that release
using ct.sym which stores diffs. See JEP 247.
best regards,
michael bien
Hi,
To me upgrading to "--source 17 --target 17" sounds like a good idea.
Tom
Am 19.07.22 um 15:44 schrieb Kevin Rushforth:
Even though we build JavaFX binaries with JDK 18 as the boot JDK, the
latest version of JavaFX still runs with JDK 11 (and is capable of being
built using JDK 12 or late
I've read the various comments so far and so have weighed those and my
view is that
it is about time to move on from JDK11 and think a policy of making the
minimum an LTS is a
reasonable position - so JDK 17 LTS is what comes out of that today.
What to do in future (ie what is the policy) is a
On Tue, 19 Jul 2022 20:18:14 GMT, Andy Goryachev wrote:
> John, thank you for your comments!
>
> I fully agree with the idea of not putting objects with mutable fields that
> participate in either equals() or hashCode() into Hashtable. This scenario
> might still be legitimate, for example by
On Tue, 19 Jul 2022 15:48:09 GMT, Andy Goryachev wrote:
>> - added missing hashCode() methods
>
> Andy Goryachev 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 req
I'm split on this myself :)
As JavaFX is more of a library now, and not part of the JDK, allowing
broader compatibility could be beneficial: people can get new JavaFX
features without having to upgrade the JDK (each time) as well. For me
personally, that is moot since I tend to just track the
On Tue, 19 Jul 2022 15:48:09 GMT, Andy Goryachev wrote:
>> - added missing hashCode() methods
>
> Andy Goryachev 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 req
On Mon, 18 Jul 2022 08:07:32 GMT, Abhinay Agarwal wrote:
> Add release notes for JavaFX 18.0.2 to the repository
This pull request has now been integrated.
Changeset: 367fd96d
Author:Abhinay Agarwal
Committer: Kevin Rushforth
URL:
https://git.openjdk.org/jfx/commit/367fd96d63fb89c9
On Tue, 19 Jul 2022 19:00:01 GMT, Abhinay Agarwal wrote:
>> Add release notes for JavaFX 18.0.2 to the repository
>
> Abhinay Agarwal has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add list of security fixes
Marked as reviewed by kcr (Lea
> Add release notes for JavaFX 18.0.2 to the repository
Abhinay Agarwal has updated the pull request incrementally with one additional
commit since the last revision:
Add list of security fixes
-
Changes:
- all: https://git.openjdk.org/jfx/pull/838/files
- new: https://git.op
First of all: there is often confusion when this is discussed (e.g.
on Twitter). We are only discussing the minimum JDK version for the code
in OpenJFX. JavaFX applications can of course declare stronger requirements
(e.g. Java 19 as a minimum).
I am rather cautious on bumping the minimum version
Approved
On Tue, Jul 19, 2022 at 5:35 PM Kevin Rushforth
wrote:
> Resend with correct subject line
>
> On 7/19/2022 8:32 AM, Kevin Rushforth wrote:
> > Hi Johan,
> >
> > I request approval to sync changes from to the just-released July 2022
> > CPU release into the 'jfx19' branch of the 'jfx' r
Approved.
On Tue, Jul 19, 2022 at 5:32 PM Kevin Rushforth
wrote:
> Hi Johan,
>
> I request approval to sync changes from to the just-released July 2022
> CPU release into the 'jfx19' branch of the 'jfx' repo. Here is the
> aggregate set of changes for the fixes:
>
> https://github.com/kevinrus
> - added missing hashCode() methods
Andy Goryachev 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 five additional
commits since the last revision:
On Tue, 19 Jul 2022 03:50:47 GMT, Nir Lisker wrote:
>> Andy Goryachev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8289389: minimize the impact of collision
>
> modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 2322:
Approved
On Tue, Jul 19, 2022, 17:35 Kevin Rushforth
wrote:
> Hi Johan,
>
> I request approval to backport the changes from the just-released July
> 2022 CPU to jfx:jfx18 (for 18.0.2), jfx17u (for 17.0.4) and to jfx11u
> (for 11.0.16) .
>
> https://github.com/kevinrushforth/jfx/compare/58170f4
Resend with correct subject line
On 7/19/2022 8:32 AM, Kevin Rushforth wrote:
Hi Johan,
I request approval to sync changes from to the just-released July 2022
CPU release into the 'jfx19' branch of the 'jfx' repo. Here is the
aggregate set of changes for the fixes:
https://github.com/kevin
Hi Johan,
I request approval to backport the changes from the just-released July
2022 CPU to jfx:jfx18 (for 18.0.2), jfx17u (for 17.0.4) and to jfx11u
(for 11.0.16) .
https://github.com/kevinrushforth/jfx/compare/58170f4409...18-cpu-2207-sync
https://github.com/kevinrushforth/jfx17u/compare/
Hi Johan,
I request approval to sync changes from to the just-released July 2022
CPU release into the 'jfx19' branch of the 'jfx' repo. Here is the
aggregate set of changes for the fixes:
https://github.com/kevinrushforth/jfx/compare/92cefceb68...cpu-2207-sync
NOTE: Since this is an integra
On Fri, 8 Jul 2022 20:31:31 GMT, Andy Goryachev wrote:
> Fixes "Unlikely argument type" warning generated by the latest Eclipse IDE.
>
> This warning should be reclassified as an error, as it catches bugs missed by
> javac. In this case, the following places seem to contain bugs:
> -
> apps/s
On Tue, 19 Jul 2022 03:46:17 GMT, Nir Lisker wrote:
>> Andy Goryachev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8289389: minimize the impact of collision
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeViewT
There was a desire by some developers to keep JavaFX runnable with the
most recent LTS of the JDK. I think it might be a harder sell to bump
the minimum to 18. I'd love to hear from more developers on this.
Regarding code snippets, as long as it doesn't break the build if we use
them, I don't
Why is the bump to JDK 17 and not 18? In 18 the feature for Code Snippets
in Java API Documentation was added and it could be useful for any new API.
Is the plan to continue to pump the minimum version with every release or
once in several? Does it depend on the benefit the new features add?
On T
Even though we build JavaFX binaries with JDK 18 as the boot JDK, the
latest version of JavaFX still runs with JDK 11 (and is capable of being
built using JDK 12 or later, and with some limitations, using JDK 11),
although it isn't tested with older JDK versions. In order for JavaFX to
be able
> Do not recalculate total estimated size recursively.
>
> In the (unlikely) event that the recalculation triggers a new recalculation
> (e.g. when the height of a Cell is changed), do not start this recalculation.
> The cache and cache size may become inconsistent if a recursive calculation
> i
On Sun, 17 Jul 2022 18:59:22 GMT, Johan Vos wrote:
>> Do not recalculate total estimated size recursively.
>>
>> In the (unlikely) event that the recalculation triggers a new recalculation
>> (e.g. when the height of a Cell is changed), do not start this recalculation.
>> The cache and cache si
33 matches
Mail list logo
