On Sat, 17 May 2025 12:24:46 GMT, Michael Strauß wrote:
>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX
>> application freezes. The reason is that the user exception will bubble up
>> into framework code, preventing the normal operation of JavaFX.
>>
>> The following p
On Sat, 17 May 2025 12:24:46 GMT, Michael Strauß wrote:
>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX
>> application freezes. The reason is that the user exception will bubble up
>> into framework code, preventing the normal operation of JavaFX.
>>
>> The following p
On Mon, 19 May 2025 18:05:39 GMT, Michael Strauß wrote:
>> 100 still looks excessive to me - it's unlikely that we'll have two
>> different scenarios when this happens, so most of the time the log will have
>> 100 identical traces.
>>
>> I mean, one is probably enough, we could have 2 or 4 jus
On Sat, 17 May 2025 12:24:46 GMT, Michael Strauß wrote:
>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX
>> application freezes. The reason is that the user exception will bubble up
>> into framework code, preventing the normal operation of JavaFX.
>>
>> The following p
On Mon, 19 May 2025 15:30:17 GMT, Andy Goryachev wrote:
>> I've removed the system property, so there's a hard-coded limit of 100
>> exceptions now.
>
> 100 still looks excessive to me - it's unlikely that we'll have two different
> scenarios when this happens, so most of the time the log will
On Sat, 17 May 2025 12:21:17 GMT, Michael Strauß wrote:
>> On the other hand, AnimationTimer is a public API that allows for arbitrary
>> code execution, which always has the potential to fail for any number of
>> reasons (think of calling an unstable API from the timer callback). We can’t
>>
> When an exception is thrown from `AnimationTimer::handle`, the JavaFX
> application freezes. The reason is that the user exception will bubble up
> into framework code, preventing the normal operation of JavaFX.
>
> The following program demonstrates the defect:
>
>
> public class FailingAni
On Fri, 16 May 2025 19:18:28 GMT, Michael Strauß wrote:
>> It just seems unnecessary to add all this complexity. The first exception
>> is all we need, really - we can skip the 2nd, 3rd, ... This might rule out
>> the property.
>>
>> It might be unlikely that two or more completely unrelated
On Fri, 16 May 2025 19:03:21 GMT, Andy Goryachev wrote:
>> We could also just keep it with a fixed threshold, but remove the system
>> property.
>
> It just seems unnecessary to add all this complexity. The first exception is
> all we need, really - we can skip the 2nd, 3rd, ... This might ru
On Fri, 16 May 2025 18:52:57 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java
>> line 352:
>>
>>> 350: }
>>> 351:
>>> 352: private static abstract class ReceiverRecord {
>>
>> All this does look complicated, just
On Fri, 16 May 2025 19:03:14 GMT, Michael Strauß wrote:
>> We're throwing away all exceptions after a certain point (either after the
>> first, or some number of exceptions after that). A potential use case would
>> be debugging a large application that for some reason throws lots of
>> differ
On Fri, 16 May 2025 18:47:03 GMT, Andy Goryachev wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review comments
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java
> l
On Fri, 16 May 2025 18:12:35 GMT, Michael Strauß wrote:
>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX
>> application freezes. The reason is that the user exception will bubble up
>> into framework code, preventing the normal operation of JavaFX.
>>
>> The following p
On Fri, 16 May 2025 18:27:14 GMT, Andy Goryachev wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review comments
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java
> l
On Fri, 16 May 2025 18:12:35 GMT, Michael Strauß wrote:
>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX
>> application freezes. The reason is that the user exception will bubble up
>> into framework code, preventing the normal operation of JavaFX.
>>
>> The following p
On Fri, 16 May 2025 18:12:35 GMT, Michael Strauß wrote:
>> When an exception is thrown from `AnimationTimer::handle`, the JavaFX
>> application freezes. The reason is that the user exception will bubble up
>> into framework code, preventing the normal operation of JavaFX.
>>
>> The following p
On Fri, 16 May 2025 17:51:40 GMT, Andy Goryachev wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review comments
>
> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/AbstractPrimaryTimer.java
> l
> When an exception is thrown from `AnimationTimer::handle`, the JavaFX
> application freezes. The reason is that the user exception will bubble up
> into framework code, preventing the normal operation of JavaFX.
>
> The following program demonstrates the defect:
>
>
> public class FailingAni
On Fri, 16 May 2025 14:38:20 GMT, Michael Strauß wrote:
> When an exception is thrown from `AnimationTimer::handle`, the JavaFX
> application freezes. The reason is that the user exception will bubble up
> into framework code, preventing the normal operation of JavaFX.
>
> The following progra
When an exception is thrown from `AnimationTimer::handle`, the JavaFX
application freezes. The reason is that the user exception will bubble up into
framework code, preventing the normal operation of JavaFX.
The following program demonstrates the defect:
public class FailingAnimationTimer exte
20 matches
Mail list logo
