Re: Swing/AWT concurrency

Hello,
Am 11/08/2021 um 16:03 schrieb Brian S O'Neill:
> I should have been more clear here. Gregg's example awhile back showed 
> how easy it was for a new user to inadvertently create a 
> multi-threaded swing app, simply because the thread which created the 
> JFrame was "main", which then underneath the covers created a second 
> thread for processing events. This problem could be avoided if the app 
> must be launched via a callback (to ensure it's running in the event 
> loop thread), or if the app itself was responsible for driving events, 
> and thus no extra thread would be created.

Javafx offers to Subclass javafx.application.Application as an 
alternative of providing a "main" method. As for swing I would agree 
that its not beginner friendly that you need to remember that your first 
Statement should be SwingUtilities.invokeLater() and if you forget it 
you dont get a stern error like you get from javafx, instead it works 
sometimes, and sometimes not... Not the end of the world though.

Best regards,

Thorsten


>
> -- Brian
>
> On 2021-08-11 12:25 AM, Thorsten wrote:
>> Hello,
>>
>> Am 11/08/2021 um 04:17 schrieb Brian S O'Neill via Concurrency-interest:
>>>
>>> I've not looked at JavaFX. Is it a rewrite, or is it layered on top 
>>> of AWT just like Swing? Is it single-threaded from the user's 
>>> perspective, or does it suffer all the same problems by trying to be 
>>> multi-threaded? 
>>
>> JavaFX is single-Threaded, Platform.runLater(). Swing is also 
>> single-Threaded, SwingUtilities.invokeLater(). They can also be put 
>> on the same thread. I cannot comment on how threading was supposed to 
>> be handled in pure AWT, but swing renders this question kinda 
>> obsolete since 1998, thats more than 20 years...
>>
>> Best regards,
>>
>> Thorsten
>>
>>
>> .