Not really a nice comment but a real issue?

Fri Mar 19 16:29:08 UTC 2021

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.duquevieira at 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://www.youtube.com/watch?v=RELKg32xEWU
>>>>> 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://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/
>>>>>>>
>>>>>>> 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://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered 
>>>>
>>>>>>> -- 
>>>>>>> Cl?ment Levallois
>>>>>>> Associate Professor
>>>>>>> emlyon business school
>>>>>>> Twitter and Skype: @seinecle
>>>>>>> mobile: +33(0)6 59 08 33 92
>>>>>>>
>>>>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>>
>>> -- 
>>> Pedro Duque Vieira - https://www.pixelduke.com
>