Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]

Seeon Birger seeon.birger at
Thu Jan 23 09:09:54 PST 2014


I wonder if we could take advantage of available plug-ins for JIRA.

I particular I found this one which enables threaded comments for JIRA:

Also interesting is the following which make it easy to put JIRA updates on mailing lists in a flexible and customizable way:

What do you think?


-----Original Message-----
From: Stephen F Northover 
Sent: Thursday, January 23, 2014 12:45 AM
To: John Hendrikx; openjfx-dev at
Subject: Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]

Hi John,

The goal is not to end the discussion!

It's a trade off.  Mailing lists are good because they provide a threaded discussion.  JIRA is bad because it is not threaded.  JIRA has the advantage that it captures data in a single place and provides a good history of why a decision was made.

There's no right answer here but the policy that the FX committers is using is to try to capture as much as possible in JIRA.


On 2014-01-22 5:29 PM, John Hendrikx wrote:
> Unfortunately, "discussing" things in JIRA works very poorly and is a 
> good way to end a productive discussion IMHO.  Mailinglists are much 
> better suited to the task, as thousands of interesting mailinglists 
> accross many developer communities will atest to.
> Keeping a record is good, aren't these mailinglists archived?
> --John
> On 22/01/2014 18:47, Daniel Blaukopf wrote:
>> Hi Martin, Randahl, Tom, Richard, Tomas and Ali,
>> This is a productive discussion, but once we get to this level of 
>> detail JIRA is the place to have it, so that we don't lose our record 
>> of it. Would you continue the discussion on
>> ?
>> See
>> s-TechnicalDiscussionsandCodeReviews
>> Thanks,
>> Daniel
>> On Jan 22, 2014, at 7:23 PM, Stephen F 
>> Northover<steve.x.northover at>  wrote:
>>> If we add this API, I like addListener(InvalidationListener,
>>> boolean) better than ensureListener().
>>> Steve
>>> On 2014-01-22 8:20 AM, Ali Ebrahimi wrote:
>>>> I suggest adding another overload for addListener method taking 
>>>> boolean parameter  "duplicateAllowed" or "duplicateNotAllowed".
>>>> On Wed, Jan 22, 2014 at 3:00 PM, Richard 
>>>> Bair<richard.bair at>wrote:
>>>>>>> The default implementation (for Observable) would look like this:
>>>>>>> public default void ensureListener(InvalidationListener listener) {
>>>>>>>     removeListener(listener);
>>>>>>>     addListener(listener);
>>>>>>> }
>>>>>>> subclasses might do something more effective. The same would 
>>>>>>> apply to
>>>>>>> ObservableValue and ChangeListener and Observable[List|Set|Map] and
>>>>>>> [List|Set|Map]ChangeListener.
>>>>>> Well this would destroy the order! I expect listeners to be 
>>>>>> called in
>>>>>> the correct order not?
>>>>> That's a good point :-(
>>>>>> Why doing a remove and not simply check if the
>>>>>> listener has already been added?
>>>>> Because there is no way to check, except in the implementation. 
>>>>> From the
>>>>> Observable interface level, there is no way to a) force all 
>>>>> implementations
>>>>> of the interface to implement the method correctly (without 
>>>>> breaking source
>>>>> compatibility anyway), or b) to provide a reasonable default 
>>>>> implementation.
>>>>> Maybe this is one of those things we can't fix on the Observable 
>>>>> interface
>>>>> and just have to provide implementations of on our concrete 
>>>>> properties.
>>>>> Richard

More information about the openjfx-dev mailing list