Thank you, Dirk.
I'll make sure that the obvious bug of reading from an unbuffered stream
is fixed for FX 17. No promises on the enhancements, of course.
-- Kevin
On 3/19/2021 9:34 AM, Dirk Lemmermann wrote:
I took the liberty of informing the author of the blog. It was hard not to
comment on the tone he used ….. but we all know that never leads to anything.
Let the facts speak for themselves and they tell him that he was heard and his
findings resulted in tickets and hopefully fixes soon.
Dirk
On Mar 19, 2021, at 5:29 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote:
https://bugs.openjdk.java.net/browse/JDK-8263886
On 3/19/2021 9:17 AM, Kevin Rushforth wrote:
That's an interesting idea about looking at the HTTP response headers and
checking to see whether the file has changed. If it could be done in such a way
that it minimizes overhead, it might be the best of both worlds. I'll file an
RFE to look into that...not sure we'll get time to do it, though, so if someone
from the community wants to take it, that would help.
Regarding an "opt out" mechanism, If someone wants to propose an API to do that, we'd be happy to
consider it (as with the above, it will be more likely to get done if someone volunteers to drive it to
completion). The main question I can think of that would need to be answered is: what should be the
granularity of the new boolean attribute? Global (probably on Platform then)? Per Scene? Per Region (which
would also need to be on the Scene with Region overriding it)? Another is around what the behavior should be
of setting it from "false" back to the (default) "true".
-- Kevin
On 3/19/2021 9:08 AM, Richard Bair wrote:
Hey everybody!
These all sound like really good points. I agree with Pedro that the ability to
auto-reload (especially during development) is a really great thing, but I
agree with the blog post and Clemens that in production this can be problematic
depending on the location of the source CSS file, and in any event does
introduce some performance overhead that would be nice to avoid.
Could JavaFX look at response headers when loading CSS over HTTP/S to determine
whether the CSS file can be cached and then maintain a local cache for such CSS
files? That would resolve one particular issue where CSS is loaded remotely.
Could JavaFX use a different mechanism for watching the CSS files when loaded
from disk so that it isn’t re-read every time but only when a change had been
detected? I think both of those enhancements could probably be done while
remaining consistent with the existing semantics. Add the Bug fix in that Kevin
mentioned and I think most of the practical problems raised by the blog post
would be fixed.
Cheers
Richard
On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira <pedro.duquevie...@gmail.com>
wrote:
In the blog post he makes it sounds like it isn't good for anything to have
that. That it is just a bug, something that wasn't well thought through and
reviewed or a pointless feature. Which I totally disagree with. I think it
can be very interesting to take advantage of that.
I think the performance problem he measured was more about the buffering
issue than about dynamically reloading the stylesheet whenever there's a
change. But yeah, this might have a performance impact. If there is indeed
a considerable impact, perhaps we could have a flag to opt out of this
feature. That way we can have the best of both worlds and not have this
feature impact the apps performance in production.
Cheers,
A good feature during development is not necessarily a good feature during
production, especially if it (apparently) has a significant performance
impact.
But I see your point.
On 19-3-2021 15:32, Pedro Duque Vieira wrote:
Hi
I actually totally disagree with his conclusion.
In fact, I'd say, that's one of the hidden gems of JavaFX!
Check out CSSFX and this video
https://urldefense.com/v3/__https://www.youtube.com/watch?v=RELKg32xEWU__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vTw53GCg$
to understand the advantages of this feature (ScenicView has also
integrated CSSFX to take advantage of this).
Think about the productivity boost of tweaking your UI at runtime and not
having to go through the cycle: tweak UI -> compile -> run -> (No that's
not it) -> close app -> tweak UI again -> compile again -> run again ->
(No
that's not it again) -> [repeat till infinity]
Also think about the potential for adding tools that build on top of this
feature. Tools like firebug or features from Chrome developer tools, etc,
that they use on the web to debug / tweak UIs during runtime.
Cheers,
On 19-3-2021 14:29, Clement Levallois wrote:
Hi all,
I just came across this blog post which complains about a badly
implemented stream reader in JavaFX. The general tone is not nice, but I
figured this could be useful to the developers maintaining this area:
https://urldefense.com/v3/__https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vdMXtREi$
Best regards,
Clement
PS: I landed on this blog post because I was searching for some
pointers
on a coding problem I have with JavaFX Service / Task, which might or
might
not involve inputStreams. I share it here:
https://urldefense.com/v3/__https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vVAiFenV$
--
Cl?ment Levallois
Associate Professor
emlyon business school
Twitter and Skype: @seinecle
mobile: +33(0)6 59 08 33 92
Sent with
[ProtonMail](https://urldefense.com/v3/__https://protonmail.com__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vZM09C8y$
) Secure Email.
--
Pedro Duque Vieira -
https://urldefense.com/v3/__https://www.pixelduke.com__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vcWTLKUu$
