"Execution optimizations have been disabled for task" during building

[Nir Lisker]

Hi,

When running builds, gradle reports

Execution optimizations have been disabled for task
':base:copyClassFilesWin' to ensure correctness due to the following
reasons:
  - Gradle detected a problem with the following location:
'C:\...\jfx\modules\javafx.base\build\module-classes'. Reason: Task
':base:copyClassFilesWin' uses this output of task ':base:buildModuleWin'
without declaring an explicit or implicit dependency. This can lead to
incorrect results being produced, depending on what order the tasks are
executed. Please refer to
https://docs.gradle.org/7.0.1/userguide/validation_problems.html#implicit_dependency
for more details about this problem.

Same happens on other tasks:
:base:copyLibFilesWin
:base:modularJarStandaloneWin
:base:copyLibFilesStandaloneWin
etc.

I don't remember seeing this before. It doesn't cause any failures but
thought I'd ask.

Re: Re-examine the risks of JDK-8264770 breaking third party libraries and applications.

[Nir Lisker]

I'll try to change the behavior locally and see how much of JavaFX breaks
as a result. I don't think that a lot of code relies on the property being
in a valid state while in fact it isn't when attaching a listener. I could
be wrong...

On Sun, Aug 29, 2021 at 6:23 PM John Hendrikx  wrote:

>
>
> On 29/08/2021 01:34, Nir Lisker wrote:
> >>
> >> This actually isn't an issue because adding an invalidation listener
> >> revalidates the property as well (I'm not sure why, but I noticed this
> >> before while working on fluent bindings).
> >>
> >
> > There is an open issue on this:
> > https://bugs.openjdk.java.net/browse/JDK-8208750.
> >
> > This is also the cause for the When binding evaluating the 'false' branch
> > unneededly. Maybe this is a good time to have a look if this can be
> > changed. The problem is finding how much code relies on this unspecified
> > behavior.
>
> Yeah, I fear that changing this now may introduce subtle problems, both
> in JavaFX itself and quite some user and library code.
>
> Invalidation and ChangeListeners are quite often chosen without much
> thought in user code, where the consideration is more whether you want
> the old value or whether you want to avoid boxing.  Such code just calls
> "get" to make it similar to a ChangeListener, even though there still is
> a subtle difference which, in the current implementation, is hidden.
>
> Current code using the invalidation + get variant would break if the
> property in question was already invalid at the time of registration, as
> then no further invalidations would be received in the absence of
> something external revalidating that property. Once it is revalidated
> once, the code would function as "intended", which further hides the
> problem (ie, problem only occurs once or only at startup or something).
>
> If fixing this proves too risky, we probably should document
> Bindings#when with a warning and perhaps offer an alternative (fluent
> bindings or a new Bindings method that just takes a mapping function :)).
>
> --John
>
>
>
>
>
>

RFR: 8263095: Provide a way for a custom control to indicate that its userAgentStyleSheet has changed

[Alessandro Parisi]

>
> OK, I think you've answered my first and third questions. The broader
> question then is whether this fills a general need, and if so, is
> allowing for a dynamic user agent style on a Control the best way to
> provide this feature? I'd like to hear from some of the other developers
> on this list.
>
> As for the second question, I don't think the API you propose for
> dynamic user agent style-sheets is feasible in a way that maintains
> compatibility. The current API model is that the control itself provides
> its userAgentStylesheet by overriding the get method, returning a String
> specific to that control (or possibly a specific instance of that
> control, if the designer of that control wants to add such logic for
> some reason). You can't compatibly turn this API into a standard
> property. Our properties have final set/get/property methods for a
> reason. Namely, to satisfy the invariant that calling the set or get
> method is identical to calling the property method (this is key to
> allowing bindings and listeners to work in a consistent and predictable
> manner). Also, since existing controls that override the getter, they
> will know nothing about the setter. Applications may wonder why
> setUserAgentStylesheet(sheet) does not imply
> sheet.equals(getUserAgentStyleSheet()).
>
> Off the top of my head I can think of three ways to resolve this
> depending on what app developers and custom controls developers would
> prefer to see:
>
> A. Provide a property with some other name (i.e., not
> userAgentStylesheet). If the value of this new property is non-null it
> takes precedence over the userAgentStylesheet. When it changes, it
> causes the necessary reevaluation to happen. This is the closest to what
> you propose, but preserves backward compatibility. This add some
> additional complexity, which may or may not be justified.
>
> B. Provide an "updateUserAgentStylesheet(String)" method that acts
> "like" a setter, but a control would be free to ignore (and a control
> that overrides the "getter" today would certainly ignore). This seems
> messy and has its own consistency issues. And it still doesn't solve the
> question of how the control indicates that it has change its user agent
> stylesheet.
>
> C. Leave it up to the control to decide when and how to change the value
> of its userAgentStylesheet. Provide a boolean
> "dynamicUserAgentStylesheet" property indicating whether the
> userAgentStylesheet is dynamic (most likely likely the control would set
> it for itself). There might also need to be a way for a control to
> indicate that its value has changed. Given your use cases, this seems
> like a good fit.
>
> There may be more options - e.g., a hybrid of B and C if setting this
> under app control is a thing many apps want to do (although in that
> case, why not just go with option A)? Maybe there something else I'm not
> thinking of right now that would work.
>
> A follow-up question is whether and how this would interact with the
> proposed theming API that is also under discussion (maybe that
> discussion could be revived)?
>
> Before we spend too much more time on the API discussion, I want to hear
> from other developers on the list as to the value proposition of doing
> this and how they would like to see it done.
>
> -- Kevin
>
>
I would exclude A and C solutions as they would add some
unnecessary complexity in my opinion. I kinda like solution B, I like the
idea of an update method, but I don't see how a control would be able to
ignore it. Also, let's say a control overrides the getter, why a call to
the "update" method should be ignored, it's up to the user to decide if the
userAgent should be changed right?

To be honest, these solutions, and particularly the B one, seem to be good
solution if you want to keep backwards compatibility but let's suppose
solution B is implemented, we end up having to methods for the userAgent a
"getter" and an "updater". At this point, without taking into account
backwards compatibility, I'd rather delete the "getter" and keep only the
"updater", apps/libraries that override the getter would just need to
remove the override and instead make a call to the "updater" in the
constructor or in an "initializer" method of some sort

As for the theming API there's one thing that I don't understand. If we
introduce a theming API then what's the point of the userAgentStylesheet
exactly?

Re: RFR: 8270107: Open source FXMediaPlayer test app

[Scott Palmer]

On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev  
wrote:

> - Added FXMediaPlayer test application.
>  - This app uses all media APIs and very handy in verifying media builds 
> during development.
>  - It can be compiled and run by running "ant" and "ant run" in 
> tests/manual/media/FXMediaPlayer.

> On Aug 28, 2021, at 11:51 AM, Kevin Rushforth ***@***.***> wrote:
> 
> 
> I agree with getting it in now (after testing) and then improving it after it 
> is in the repo.
> 
> Btw, the nbproject/ files were derived from those in the apps/toys/ 
> directory, for example, apps/toys/Hello/nbproject/ 
> ,
>  and similarly are used to build using ant. So they aren't really IDE files 
> any longer, even though that's where they originated back in the FX 2 time 
> frame.
> 
> A good cleanup effort would be to rewrite them to remove the NetBeans project 
> structure, but that would be a larger effort than just this one manual test 
> program.
> 


Would be nice to have part of the cleanup convert projects to Gradle to be 
consistent with the rest of the project.

Scott

-

PR: https://git.openjdk.java.net/jfx/pull/613

Re: Re-examine the risks of JDK-8264770 breaking third party libraries and applications.

[John Hendrikx]

On 29/08/2021 01:34, Nir Lisker wrote:


This actually isn't an issue because adding an invalidation listener
revalidates the property as well (I'm not sure why, but I noticed this
before while working on fluent bindings).



There is an open issue on this:
https://bugs.openjdk.java.net/browse/JDK-8208750.

This is also the cause for the When binding evaluating the 'false' branch
unneededly. Maybe this is a good time to have a look if this can be
changed. The problem is finding how much code relies on this unspecified
behavior.


Yeah, I fear that changing this now may introduce subtle problems, both 
in JavaFX itself and quite some user and library code.


Invalidation and ChangeListeners are quite often chosen without much 
thought in user code, where the consideration is more whether you want 
the old value or whether you want to avoid boxing.  Such code just calls 
"get" to make it similar to a ChangeListener, even though there still is 
a subtle difference which, in the current implementation, is hidden.


Current code using the invalidation + get variant would break if the 
property in question was already invalid at the time of registration, as 
then no further invalidations would be received in the absence of 
something external revalidating that property. Once it is revalidated 
once, the code would function as "intended", which further hides the 
problem (ie, problem only occurs once or only at startup or something).


If fixing this proves too risky, we probably should document 
Bindings#when with a warning and perhaps offer an alternative (fluent 
bindings or a new Bindings method that just takes a mapping function :)).


--John