Re: RFR: 8343196: Add build property to identify experimental builds of JavaFX [v2]

2024-11-17 Thread Johan Vos
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

Re: RFR: 8342993: Remove uses of AccessController and AccessControlContext from JavaFX [v3]

2024-11-17 Thread Kevin Rushforth
> 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

RFR: 8338000: Remove GlassFullscreenWindow

2024-11-17 Thread Martin Fox
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

Re: RFR: 8343196: Add build property to identify experimental builds of JavaFX [v2]

2024-11-17 Thread Johan Vos
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

Re: jextract on JavaFx

2024-11-17 Thread Johan Vos
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

jextract on JavaFx

2024-11-17 Thread Thiago Milczarek Sayão
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

Re: jextract on JavaFx

2024-11-17 Thread Thiago Milczarek Sayão
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

Re: RFR: 8343196: Add build property to identify experimental builds of JavaFX [v2]

2024-11-17 Thread Johan Vos
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

RFR: 8344367: Fix mistakes in FX API docs

2024-11-17 Thread Nir Lisker
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

Re: jextract on JavaFx

2024-11-17 Thread Nir Lisker
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,

Re: jextract on JavaFx

2024-11-17 Thread Nir Lisker
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