On 5/30/21 5:19 PM, John Neffenger wrote:
On 5/19/21 1:17 PM, Ty Young wrote:
Biggest things for JavaFX that I can think of is jextract, a tool for
generating Java headers from a C header, and having all binding code
written in Java.
JavaFX has been doing its own manual form of Project Pana
On 5/19/21 1:17 PM, Ty Young wrote:
Biggest things for JavaFX that I can think of is jextract, a tool for
generating Java headers from a C header, and having all binding code
written in Java.
JavaFX has been doing its own manual form of Project Panama since 2014.
Look for the string "extends
GTK4 was just released not that long ago. I don't know how much(if any
at all) code is shared between versions, but having a tool like jextract
might be useful for adding support for that. Just a guess.
Also, the bindings are different in that, for everything not a primitive
in java(except bo
I looked at jextract a while back. I got the impression that it's more
useful when you need to generate new bindings, at the very least because
there are fewer ways to make mistakes. Most of the work on JavaFX has
already been done in this area and the mistakes have been found and fixed
by now, so
Looks like the new features that we can use are:
- Switch expressions
- Records
- Text blocks
- Pattern matching for instanceof
None of them seem pressing. When we get the more complete set of pattern
matching (with switch, sealed classes, guards...) it will probably be
enough to merit an update.
If you want to learn more about Panama you can read the JEP page:
https://openjdk.java.net/jeps/412
You can also join the panama-dev list and ask questions:
https://mail.openjdk.java.net/mailman/listinfo/panama-dev
Biggest things for JavaFX that I can think of is jextract, a tool for
gene
These are all excellent points. I would add that while a new language
feature would be the biggest reason to update, there could be new JDK
API that we would want to use as an argument type or return type in a
new FX API. I'm not aware of any in the JDK 12-16 range (at least not
ones that don't
Hi,
This is an important and good discussion, and I've read a number of valid
points. To reiterate what I've always stated:
* we don't want to increase the base (JDK) version just for the sake of
increasing
* we don't want to lose significant benefits (or developer productivity) by
sticking with o
I missed seeing this reply yesterday. We can't bump the minimum to JDK
17 until at least JavaFX 18 without changing our policy that JavaFX N is
able to build and run with JDK N-1. If we were to change that we would
also need to delay our release to be after JDK 17 date (currently JavaFX
N is re
No. I've already done a full build and test using JDK 16 (and a full
build using JDK 17 ea for that matter).
-- Kevin
On 5/18/2021 5:46 PM, Eric Bresie wrote:
Are there any deprecated or removed (1) (2) dependencies that could cause
problems?
(1) https://jdk.java.net/16/release-notes#removed
Are there any deprecated or removed (1) (2) dependencies that could cause
problems?
(1) https://jdk.java.net/16/release-notes#removed
(2) https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005191.html
Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)
> On May 18, 2021 at 4:42:45
You raise a good point about whether or not it should matter if a
version is (generally considered to be) an LTS release. I wasn't
suggesting that we necessarily wait until the next LTS to consider
picking up an important new feature, just that it could be one factor. I
also would be very inter
>
> there are some advantages in being able to run with the latest JDK LTS
>
One *potential* issue with this approach is that LTS is not defined in
OpenJDK as far as I know. The LTS versions are a business decision of each
distributor. For now, they have all aligned on 8, 11, 17, but nothing
guara
I use JFX with NetBeans every day with no problems. NetBeans 12.3 and JFX
16 on OpenJDK16
SceneBuilder creates the dialogs. NetBeans writes the code. The NB JFX is
too old. You have to update from Maven (which is, itself, still stuck on
old versions of JFX -- hasn't been updated for some t
Hi,
Am Dienstag, dem 18.05.2021 um 08:17 -0700 schrieb Kevin Rushforth:
>
> In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In
> practice, though, we don't bump it for each release, as there are some
> advantages in being able to run with the latest JDK LTS. Since JavaFX 1
Sounds good, although it is a bit unfortunate that sealed classes will
only be un-previewed in JDK 17. I think this feature has great value
for reasoning about code, in particular for library development. Do
you think we could bump it directly to JDK 17, which I think is very
fitting because it's t
A very timely question. I was already planning to raise this as a
discussion after we update our boot JDK to JDK 16 (blocked by the
in-progress gradle 7 update), which I hope to do later this week.
I think that this is the right time to consider bumping the minimum
required version to run Java
Currently, JDK 11 is required for the latest version of OpenJFX. What
is the policy for bumping this requirement? Does it always correspond
to the latest JDK LTS release (the next of which will be JDK 17), or
is it independent from the release cycle of OpenJDK?
18 matches
Mail list logo
