There might be other issues with the early access. The shared NIO buffer
feature should be behavior-neutral if you don't use it. So either there
is some other issue with it, or there is a bug.
Given the number of changes since that early access, both in the JavaFX
13 code base and in the PR it
On 6/7/19 4:40 AM, Johan Vos wrote:
The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472,
addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides a
very
much wanted feature. It is important that things are done in the right way
so that the code can be maintain
, openjfx-dev-requ...@openjdk.java.net a écrit :
> Date: Fri, 7 Jun 2019 11:40:44 +0200
> From: Johan Vos
> To: "openjfx-dev@openjdk.java.net List"
> Subject: Previews for shared buffer PR
>
> The PR discussed in https://github.com/javafxports/openjdk-jfx/
The JDK has two mechanisms for introducing "experimental" features:
1. Preview features, which are new language or VM features that are
enabled by a command line switch
2. Incubator modules for new library code
Neither of those address adding API to an existing package / class in an
existing
Hi,
This is good news but may I suggest we do something similar to OpenJDK
who also has explictly marked experimental/preview features shipping in
releases who can naturally get removed in a follow up release.
I would appreciate this in contrast to not getting this feature
integrated at all in FX
Hi Johan, hi all,
I want to share some thoughts on native buffer support aka JDK-8167148:
As I and many others have pointed out in the past, better native buffer
support is a great opportunity for JavaFX to leverage the power of external
visualization libraries and frameworks. It is a great way f
The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472,
addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides a very
much wanted feature. It is important that things are done in the right way
so that the code can be maintained in the long-term future.
Therefore, feed
