The point is that we'd rather have quick reference to the historical discussion without having to cross-reference between jira and the mailing list archives (which isn't automatically done). Once you add yourself as a watcher to the jira issue you are notified of every change, in much the same way as you are emailed of the discussion on this mailing list.
A good case in point came up just today with Martin referencing historical choices made with the Observable API, but not being able to reference them as they are not recorded anywhere (and if they are, being able to search for them is not trivial - the only hope is to find them in your email client and then go off to the openjfx-dev archives and manually search through the discussions until the right thread is found). Whilst Jira search isn't great, it is better than this! In other words, I can see an upside without any downside. What troubles do you have with Jira specifically? -- Jonathan On 23/01/2014 11:29 a.m., 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 >> https://javafx-jira.kenai.com/browse/RT-25613 ? >> >> See >> https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeReviews-TechnicalDiscussionsandCodeReviews >> >> Thanks, >> Daniel >> >> On Jan 22, 2014, at 7:23 PM, Stephen F >> Northover<steve.x.northo...@oracle.com> 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.b...@oracle.com>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 >
