Re: [ jEdit-devel ] jedit api common pitfalls

[Shlomy R. <sre...@gm...>]

Is there a formal way to indicate that a method should only be called from
the EDT? (e.g. annotation)
If not, then the comment of each such method (or class, if this is true for
all class methods) should specify this.

Note that some of these methods are not related to Swing, and the reason
for requiring them to be called only from EDT is performance - eliminating
the need in synchronization. As far as I recall, all the undo/redo support
methods fall in this category - since jEdit assumes that the undo/redo is
only done by buttons / keystrokes or by running macros (which also normally
run in the EDT).

Shlomy

On Wed, Jan 11, 2012 at 4:11 PM, Matthieu Casanova
<cho...@gm...>wrote:

> I think you are both right, jEdit follows swing rules:
> http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html
>
> but sometimes apis are very complex and the user is not sure of what
> happens in the end and it is useful for those methods to tell that those
> methods have to be called on EDT.
> Another good idea for a developper is to use Substance L&F plugin, this
> one will always throw an exception when calling Swing methods from another
> thread. Maybe it will fail to detect it for markTokens() but it is still a
> good test.
>
> 2012/1/11 Jarek Czekalski <jar...@po...>
>
>> Probably my definition is not sufficient. Buffer.markTokens seems to be
>> performing painting but is not directly connected with any awt object.
>> Please help. How can one know whether he is allowed to call a method
>> from non-awt thread?
>>
>> Jarek
>>
>> Jarek Czekalski pisze:
>> > Shlomy,
>> >
>> > To help new developers, including me, it would be good to provide
>> > a definition for methods "directly related to the GUI components".
>> >
>> > Is the following definition correct and sufficient:
>> >
>> > A method requires edt thread if one of the following occures:
>> >
>> > 1. It belongs to an awt derived object, like TextArea
>> > 2. It accepts arguments being awt derived objects
>> > 3. It returns an awt derived object
>> > 4. Its documentation or its class documentation says so
>> >
>> > If it is sufficient, then all methods not fulfilling the criteria may be
>> > called from any thread.
>> >
>> > I'm trying to establish the criteria that would allow for a quick
>> > judgement whether a given code is correct or not.
>> >
>> > Thanks,
>> > Jarek
>> >
>> > Shlomy Reinstein pisze:
>> >
>> >> What you put in the wiki is correct. However, the threading
>> restrictions
>> >> related to GUI components actually come from Java/Swing and are not
>> related
>> >> to the jEdit API. The threading restrictions related to the jEdit API
>> are
>> >> methods that are not directly related to the GUI components, but such
>> that
>> >> jEdit has always assumed will always be called from the EDT (Event
>> Dispatch
>> >> Thread) - and usually, the class documentation specifies that, as you
>> >> correctly wrote.
>> >>
>> >> Shlomy
>> >>
>> >> On Tue, Jan 10, 2012 at 10:33 PM, Jarek Czekalski
>> >> <jar...@po...>wrote:
>> >>
>> >>
>> >>
>> >>> I inserted an example section. The problem is that I am too fresh to
>> >>> know the pitfalls, but I believe there are things one should do with
>> >>> special care, not to get in troubles. I hope that if someone discovers
>> >>> such a thing, especially if it is not well documented, he will mention
>> >>> it in wiki.
>> >>>
>> >>> I know it's easy to meet troubles if one doesn't appropriately handle
>> >>> threading issues. Is it correct what I put in wiki? Make corrections
>> if
>> >>> you wish, as always with wiki contents. I put a watch on all articles
>> >>> and will get notification emails on contents change.
>> >>>
>> >>> Jarek
>> >>>
>> >>> W dniu 01/10/2012 12:30 PM, Shlomy Reinstein pisze:
>> >>>
>> >>>
>> >>>> Can you provide an explanation / example of what you mean by "api
>> >>>> common pitfalls"? It would be useful to start with something (maybe
>> >>>> just fill in one or two items)
>> >>>>
>> >>>> Thanks,
>> >>>> Shlomy
>> >>>>
>> >>>> On Tue, Jan 10, 2012 at 9:57 AM, Jarek Czekalski
>> >>>> <jar...@po... <mailto:jar...@po...>> wrote:
>> >>>>
>> >>>>     If you know about any, please update our wiki article:
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> https://sourceforge.net/apps/mediawiki/jedit/index.php?title=JEdit_api_common_pitfalls
>> >>>
>> >>>
>> >>>>     At this time it is empty and only admins have access to edit the
>> >>>>
>> >>>>
>> >>> wiki.
>> >>>
>> >>>
>> >>>>     If someone else is interested in writing, please let me know.
>> >>>>
>> >>>>     By the way: creating a "broken" link and following it is the best
>> >>>>     way to
>> >>>>     create a new wiki article.
>> >>>>
>> >>>>     Jarek
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> ------------------------------------------------------------------------------
>> >>>
>> >>>
>> >>>>     Write once. Port to many.
>> >>>>     Get the SDK and tools to simplify cross-platform app development.
>> >>>>     Create
>> >>>>     new or port existing apps to sell to consumers worldwide.
>> Explore the
>> >>>>     Intel AppUpSM program developer opportunity.
>> >>>>     appdeveloper.intel.com/join <http://appdeveloper.intel.com/join>
>> >>>>     http://p.sf.net/sfu/intel-appdev
>> >>>>     --
>> >>>>     -----------------------------------------------
>> >>>>     jEdit Developers' List
>> >>>>     jEd...@li...
>> >>>>     <mailto:jEd...@li...>
>> >>>>     https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> ------------------------------------------------------------------------------
>> >>> Write once. Port to many.
>> >>> Get the SDK and tools to simplify cross-platform app development.
>> Create
>> >>> new or port existing apps to sell to consumers worldwide. Explore the
>> >>> Intel AppUpSM program developer opportunity.
>> appdeveloper.intel.com/join
>> >>> http://p.sf.net/sfu/intel-appdev
>> >>> --
>> >>> -----------------------------------------------
>> >>> jEdit Developers' List
>> >>> jEd...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
>> complex
>> > infrastructure or vast IT resources to deliver seamless, secure access
>> to
>> > virtual desktops. With this all-in-one solution, easily deploy virtual
>> > desktops for less than the cost of PCs and save 60% on VDI
>> infrastructure
>> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>> infrastructure or vast IT resources to deliver seamless, secure access to
>> virtual desktops. With this all-in-one solution, easily deploy virtual
>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>