On Sat, 16 Nov 2024 22:32:30 GMT, Kevin Rushforth wrote:
> > It is a bit confusing to have "jfx.release.suffix" and
> > "jfx.experimental.release.suffix" where the former refers to an artifact
> > property and the latter refers to a major feature/variant/... like metal.
>
> I think you have a
> This PR removes all remaining uses of `AccessController` and
> `AccessControlContext`, which represent the last remaining uses of the
> terminally deprecated security APIs except for those in the `/ios/` or
> `/android/` directories.
>
> With the removal of doPrivileged and the `if (System.ge
The GlassFullscreenWindow class hasn't been instantiated since applet support
was removed (JDK-8201538). This PR removes the class and the one (unused)
member variable of that type.
-
Commit messages:
- Merge remote-tracking branch 'upstream/master' into macfscleanup
- Removed old
On Sat, 16 Nov 2024 19:43:07 GMT, Nir Lisker wrote:
>> I agree with that. It is often useful to have timestamp info in the builds
>> during development.
>> I know I'm a broken record on this topic, but if possible, it would be great
>> if (parts of) this logic can be moved into a separate file
The latter (have the bindings generated at build time) is more in line with
other parts of OpenJFX (e.g. decora).
Also, the generated files can be large, and depend on what version of
jextract one is using.
I think it's better not to have them in the src section of the code, but to
generate them at
Hi,
Are there any plans to make a default way to use jextract (or any other way
to use ffm) on the gradle build system?
-- Thiago
I would have a system lib that would be compatible forever (theoretically)
and some C code,
but I just want to bind specific functions, structs, typedefs, vars and
constants (it's a big jextract command)
So in the need of new functions from C to java, some might need to
re-generate the bindings an
On Sat, 16 Nov 2024 22:36:17 GMT, Kevin Rushforth wrote:
> If we do this, then here are some possible names:
>
> * jfx.experimental.release
> * jfx.experimental.release.name
> * jfx.variant.release
> * jfx.variant.release.name
> * jfx.variant
> * jfx.feature.variant
>
> Thoughts?
I don't have
A batch of typo and grammar fixes that were found by the spellchecker.
Integration can wait until RDP 1/2.
-
Commit messages:
- More corrections
- Batch typo fixes
- Fix mistakes in OpenJFX docs
Changes: https://git.openjdk.org/jfx/pull/1642/files
Webrev: https://webrevs.openjd
The question is: what are you binding to? If it's a library on the OS that
gets updated from time to time and JavaFX relies on it being there (not
bundled), then the generated bindings in a task could change and break
compilation if the Java code wasn't changed. If it's a library created by
JavaFX,
jextract is something you run once to produce the FFM bindings that you
then add to your code base, there's no need to make it part of the build
(although I guess you can). I would think that If you're creating a PR that
needs FFM, use jextract to produce the java files and submit them as part
of t
11 matches
Mail list logo