[8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Hi all, I would like to start discussion about an addition to API in Observable, ObservableValue and all Observable collections. There were multiple requests for a way how to avoid duplicates in listeners lists. The way RT-25613 solves this is that it introduces public boolean hasListener(ListenerType listener) which would return true if the provided listener is already registered. This has one significant drawback that all of Observable* are actually interfaces. Means we can only add hasListener as a defender method. The problem is with the default implementation. We cannot return anything meaningful, so we have to throw an UnsupportedOperationException. The problem is that this might blow up unexpectedly when some "older" Observable implementation is used. Also, it might be easy to miss when implementing the interface, since the IDE might not force you to implement it. So as an alternative solution, I propose adding something like: ensureListener(ListenerType listener) which would make sure the listener is on the list and if a listener is already present, the number of times listener is registered on the Observable will NOT grow after this call. 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. What do you think? JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 -Martin
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Hi Martin While I agree your proposed solution would work, I still don’t understand why JavaFX should keep on supporting duplicates in listener collections. Can anyone come up with just 1 example of an application that might be depending on having two listeners on the same Observable? E.g. this kind of code: myObservable.addListener(myChangeListener); //add it myObservable.addListener(myChangeListener); //add it again In what kind of situation would this sort of code make any sense? If we all feel confident that the presence of duplicates listeners is always an error, I warmly recommend changing the API to be duplicate free. Yours Randahl On 22 Jan 2014, at 11:07, Martin Sladecek wrote: > Hi all, > I would like to start discussion about an addition to API in Observable, > ObservableValue and all Observable collections. > There were multiple requests for a way how to avoid duplicates in listeners > lists. The way RT-25613 solves this is that it introduces public boolean > hasListener(ListenerType listener) which would return true if the provided > listener is already registered. > > This has one significant drawback that all of Observable* are actually > interfaces. Means we can only add hasListener as a defender method. The > problem is with the default implementation. We cannot return anything > meaningful, so we have to throw an UnsupportedOperationException. The problem > is that this might blow up unexpectedly when some "older" Observable > implementation is used. Also, it might be easy to miss when implementing the > interface, since the IDE might not force you to implement it. > > So as an alternative solution, I propose adding something like: > > ensureListener(ListenerType listener) > > which would make sure the listener is on the list and if a listener is > already present, the number of times listener is registered on the Observable > will NOT grow after this call. > > 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. > > What do you think? > > JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 > > -Martin
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
The reason why this was decided this way is simple : performance. You usually don't (try to) add a listener twice, so in most cases it doesn't make sense to check for duplicates every time a listener is added. So we currently leave the burden of avoiding duplicates on the developer. -Martin On 01/22/2014 11:23 AM, Randahl Fink Isaksen wrote: Hi Martin While I agree your proposed solution would work, I still don’t understand why JavaFX should keep on supporting duplicates in listener collections. Can anyone come up with just 1 example of an application that might be depending on having two listeners on the same Observable? E.g. this kind of code: myObservable.addListener(myChangeListener); //add it myObservable.addListener(myChangeListener); //add it again In what kind of situation would this sort of code make any sense? If we all feel confident that the presence of duplicates listeners is always an error, I warmly recommend changing the API to be duplicate free. Yours Randahl On 22 Jan 2014, at 11:07, Martin Sladecek wrote: Hi all, I would like to start discussion about an addition to API in Observable, ObservableValue and all Observable collections. There were multiple requests for a way how to avoid duplicates in listeners lists. The way RT-25613 solves this is that it introduces public boolean hasListener(ListenerType listener) which would return true if the provided listener is already registered. This has one significant drawback that all of Observable* are actually interfaces. Means we can only add hasListener as a defender method. The problem is with the default implementation. We cannot return anything meaningful, so we have to throw an UnsupportedOperationException. The problem is that this might blow up unexpectedly when some "older" Observable implementation is used. Also, it might be easy to miss when implementing the interface, since the IDE might not force you to implement it. So as an alternative solution, I propose adding something like: ensureListener(ListenerType listener) which would make sure the listener is on the list and if a listener is already present, the number of times listener is registered on the Observable will NOT grow after this call. 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. What do you think? JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 -Martin
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
On 22.01.14 11:07, Martin Sladecek wrote: > Hi all, > I would like to start discussion about an addition to API in Observable, > ObservableValue and all Observable collections. > There were multiple requests for a way how to avoid duplicates in > listeners lists. The way RT-25613 solves this is that it introduces > public boolean hasListener(ListenerType listener) which would return > true if the provided listener is already registered. > > This has one significant drawback that all of Observable* are actually > interfaces. Means we can only add hasListener as a defender method. The > problem is with the default implementation. We cannot return anything > meaningful, so we have to throw an UnsupportedOperationException. The > problem is that this might blow up unexpectedly when some "older" > Observable implementation is used. Also, it might be easy to miss when > implementing the interface, since the IDE might not force you to > implement it. > > So as an alternative solution, I propose adding something like: > > ensureListener(ListenerType listener) > > which would make sure the listener is on the list and if a listener is > already present, the number of times listener is registered on the > Observable will NOT grow after this call. > > 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? Why doing a remove and not simply check if the listener has already been added? Tom
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Hi Martin Then I respectfully disagree with this design decision. In my point of view, choosing performance over ease of use is rarely a good idea. Here, the performance choice has put us in a situation where no one knows how many JavaFX apps have duplicate listener bugs, and such bugs can be very hard to debug. Have anyone done any tests that prove that avoiding listener duplicates would lead to a severe performance impact? I understand, that if all observables had thousands of listeners and we searched for a possible duplicate using an inefficient linear search, we would have a problem. But if reality is that very few observables have more than 20 listeners and these could be stored in a map for efficient duplicate checking, then what is the problem? Yours Randahl On 22 Jan 2014, at 11:26, Martin Sladecek wrote: > The reason why this was decided this way is simple : performance. You usually > don't (try to) add a listener twice, so in most cases it doesn't make sense > to check for duplicates every time a listener is added. So we currently leave > the burden of avoiding duplicates on the developer. > > -Martin > > On 01/22/2014 11:23 AM, Randahl Fink Isaksen wrote: >> Hi Martin >> >> While I agree your proposed solution would work, I still don’t understand >> why JavaFX should keep on supporting duplicates in listener collections. Can >> anyone come up with just 1 example of an application that might be depending >> on having two listeners on the same Observable? E.g. this kind of code: >> >> myObservable.addListener(myChangeListener); //add it >> myObservable.addListener(myChangeListener); //add it again >> >> In what kind of situation would this sort of code make any sense? >> >> If we all feel confident that the presence of duplicates listeners is always >> an error, I warmly recommend changing the API to be duplicate free. >> >> Yours >> >> Randahl >> >> >> >> >> On 22 Jan 2014, at 11:07, Martin Sladecek wrote: >> >>> Hi all, >>> I would like to start discussion about an addition to API in Observable, >>> ObservableValue and all Observable collections. >>> There were multiple requests for a way how to avoid duplicates in listeners >>> lists. The way RT-25613 solves this is that it introduces public boolean >>> hasListener(ListenerType listener) which would return true if the provided >>> listener is already registered. >>> >>> This has one significant drawback that all of Observable* are actually >>> interfaces. Means we can only add hasListener as a defender method. The >>> problem is with the default implementation. We cannot return anything >>> meaningful, so we have to throw an UnsupportedOperationException. The >>> problem is that this might blow up unexpectedly when some "older" >>> Observable implementation is used. Also, it might be easy to miss when >>> implementing the interface, since the IDE might not force you to implement >>> it. >>> >>> So as an alternative solution, I propose adding something like: >>> >>> ensureListener(ListenerType listener) >>> >>> which would make sure the listener is on the list and if a listener is >>> already present, the number of times listener is registered on the >>> Observable will NOT grow after this call. >>> >>> 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. >>> >>> What do you think? >>> >>> JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 >>> >>> -Martin >
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
On 01/22/2014 11:27 AM, Tom Schindl wrote: On 22.01.14 11:07, Martin Sladecek wrote: Hi all, I would like to start discussion about an addition to API in Observable, ObservableValue and all Observable collections. There were multiple requests for a way how to avoid duplicates in listeners lists. The way RT-25613 solves this is that it introduces public boolean hasListener(ListenerType listener) which would return true if the provided listener is already registered. This has one significant drawback that all of Observable* are actually interfaces. Means we can only add hasListener as a defender method. The problem is with the default implementation. We cannot return anything meaningful, so we have to throw an UnsupportedOperationException. The problem is that this might blow up unexpectedly when some "older" Observable implementation is used. Also, it might be easy to miss when implementing the interface, since the IDE might not force you to implement it. So as an alternative solution, I propose adding something like: ensureListener(ListenerType listener) which would make sure the listener is on the list and if a listener is already present, the number of times listener is registered on the Observable will NOT grow after this call. 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? Why doing a remove and not simply check if the listener has already been added? Tom Because there's no way to do it in the interface, hence the problem with hasListener default implementation. Yes, the order would be broken, but it's actually not guaranteed. Although FX internally uses a List, 3rd party implementations of Observable or ObservableValue might use a Set for listeners for example. This was the idea, but funnily enough, the current Observable javadoc is quite strict on the duplicates which would rule out the Set: /** * Adds an {@link InvalidationListener} which will be notified whenever the * {@code Observable} becomes invalid. If the same * listener is added more than once, then it will be notified more than * once. That is, no check is made to ensure uniqueness. Personally, I would rather make this requirement less strict and allow both List backed and Set backed implementations. -Martin
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
On 01/22/2014 11:38 AM, Randahl Fink Isaksen wrote: Hi Martin Then I respectfully disagree with this design decision. In my point of view, choosing performance over ease of use is rarely a good idea. Here, the performance choice has put us in a situation where no one knows how many JavaFX apps have duplicate listener bugs, and such bugs can be very hard to debug. Have anyone done any tests that prove that avoiding listener duplicates would lead to a severe performance impact? I'm not the original author of the Observable API, but I remember there were many performance tests back at the days before 2.0 release, esp. when such API decision was made. So likely, the tests were done, but the results were not archived or anything. I understand, that if all observables had thousands of listeners and we searched for a possible duplicate using an inefficient linear search, we would have a problem. But if reality is that very few observables have more than 20 listeners and these could be stored in a map for efficient duplicate checking, then what is the problem? Well it's always a balance between performance, dynamic footprint (a set/map for duplicates) and API. Having an API that extensively checks for all the mistakes a developer can do is an extreme case in the same manner as an API that does not check input at all. If a cleanup of some listeners is missing, it's a developer's bug (memory leak) no matter if there a duplicate listener check or not on the subsequent addListener call when the object becomes "valid" again (or whatnot). I understand your position, there are APIs I would also like to behave differently, but the decision was already made, it's too late for the discussion. There might be 3rd implementations that use a list a don't guarantee a duplicate check, we don't want to make them suddenly "broken". I also disagree that such bugs are hard to debug, a simple printout should do. In many cases it would likely just make a computations run more times than necessary. I can imagine doing a duplicate check on something like -Djavafx.debug=true. Regards, -Martin Yours Randahl On 22 Jan 2014, at 11:26, Martin Sladecek wrote: The reason why this was decided this way is simple : performance. You usually don't (try to) add a listener twice, so in most cases it doesn't make sense to check for duplicates every time a listener is added. So we currently leave the burden of avoiding duplicates on the developer. -Martin On 01/22/2014 11:23 AM, Randahl Fink Isaksen wrote: Hi Martin While I agree your proposed solution would work, I still don’t understand why JavaFX should keep on supporting duplicates in listener collections. Can anyone come up with just 1 example of an application that might be depending on having two listeners on the same Observable? E.g. this kind of code: myObservable.addListener(myChangeListener); //add it myObservable.addListener(myChangeListener); //add it again In what kind of situation would this sort of code make any sense? If we all feel confident that the presence of duplicates listeners is always an error, I warmly recommend changing the API to be duplicate free. Yours Randahl On 22 Jan 2014, at 11:07, Martin Sladecek wrote: Hi all, I would like to start discussion about an addition to API in Observable, ObservableValue and all Observable collections. There were multiple requests for a way how to avoid duplicates in listeners lists. The way RT-25613 solves this is that it introduces public boolean hasListener(ListenerType listener) which would return true if the provided listener is already registered. This has one significant drawback that all of Observable* are actually interfaces. Means we can only add hasListener as a defender method. The problem is with the default implementation. We cannot return anything meaningful, so we have to throw an UnsupportedOperationException. The problem is that this might blow up unexpectedly when some "older" Observable implementation is used. Also, it might be easy to miss when implementing the interface, since the IDE might not force you to implement it. So as an alternative solution, I propose adding something like: ensureListener(ListenerType listener) which would make sure the listener is on the list and if a listener is already present, the number of times listener is registered on the Observable will NOT grow after this call. 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. What do you think? JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 -Martin
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
>> 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
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
I respect your point of view. Thank you for a thorough response. Randahl On 22 Jan 2014, at 12:18, Martin Sladecek wrote: > On 01/22/2014 11:38 AM, Randahl Fink Isaksen wrote: >> Hi Martin >> >> Then I respectfully disagree with this design decision. In my point of view, >> choosing performance over ease of use is rarely a good idea. Here, the >> performance choice has put us in a situation where no one knows how many >> JavaFX apps have duplicate listener bugs, and such bugs can be very hard to >> debug. >> >> Have anyone done any tests that prove that avoiding listener duplicates >> would lead to a severe performance impact? > I'm not the original author of the Observable API, but I remember there were > many performance tests back at the days before 2.0 release, esp. when such > API decision was made. So likely, the tests were done, but the results were > not archived or anything. > >> >> I understand, that if all observables had thousands of listeners and we >> searched for a possible duplicate using an inefficient linear search, we >> would have a problem. But if reality is that very few observables have more >> than 20 listeners and these could be stored in a map for efficient duplicate >> checking, then what is the problem? > Well it's always a balance between performance, dynamic footprint (a set/map > for duplicates) and API. Having an API that extensively checks for all the > mistakes a developer can do is an extreme case in the same manner as an API > that does not check input at all. If a cleanup of some listeners is missing, > it's a developer's bug (memory leak) no matter if there a duplicate listener > check or not on the subsequent addListener call when the object becomes > "valid" again (or whatnot). > > I understand your position, there are APIs I would also like to behave > differently, but the decision was already made, it's too late for the > discussion. There might be 3rd implementations that use a list a don't > guarantee a duplicate check, we don't want to make them suddenly "broken". > > I also disagree that such bugs are hard to debug, a simple printout should do. > In many cases it would likely just make a computations run more times than > necessary. I can imagine doing a duplicate check on something like > -Djavafx.debug=true. > > Regards, > -Martin > > >> >> Yours >> >> Randahl >> >> >> On 22 Jan 2014, at 11:26, Martin Sladecek >> wrote: >> >>> The reason why this was decided this way is simple : performance. You >>> usually don't (try to) add a listener twice, so in most cases it doesn't >>> make sense to check for duplicates every time a listener is added. So we >>> currently leave the burden of avoiding duplicates on the developer. >>> >>> -Martin >>> >>> On 01/22/2014 11:23 AM, Randahl Fink Isaksen wrote: Hi Martin While I agree your proposed solution would work, I still don’t understand why JavaFX should keep on supporting duplicates in listener collections. Can anyone come up with just 1 example of an application that might be depending on having two listeners on the same Observable? E.g. this kind of code: myObservable.addListener(myChangeListener); //add it myObservable.addListener(myChangeListener); //add it again In what kind of situation would this sort of code make any sense? If we all feel confident that the presence of duplicates listeners is always an error, I warmly recommend changing the API to be duplicate free. Yours Randahl On 22 Jan 2014, at 11:07, Martin Sladecek wrote: > Hi all, > I would like to start discussion about an addition to API in Observable, > ObservableValue and all Observable collections. > There were multiple requests for a way how to avoid duplicates in > listeners lists. The way RT-25613 solves this is that it introduces > public boolean hasListener(ListenerType listener) which would return true > if the provided listener is already registered. > > This has one significant drawback that all of Observable* are actually > interfaces. Means we can only add hasListener as a defender method. The > problem is with the default implementation. We cannot return anything > meaningful, so we have to throw an UnsupportedOperationException. The > problem is that this might blow up unexpectedly when some "older" > Observable implementation is used. Also, it might be easy to miss when > implementing the interface, since the IDE might not force you to > implement it. > > So as an alternative solution, I propose adding something like: > > ensureListener(ListenerType listener) > > which would make sure the listener is on the list and if a listener is > already present, the number of times listener is registered on the > Observable will NOT grow after
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
On Wed, Jan 22, 2014 at 11:27 AM, Tom Schindl wrote: > On 22.01.14 11:07, Martin Sladecek wrote: > > Hi all, > > I would like to start discussion about an addition to API in Observable, > > ObservableValue and all Observable collections. > > There were multiple requests for a way how to avoid duplicates in > > listeners lists. The way RT-25613 solves this is that it introduces > > public boolean hasListener(ListenerType listener) which would return > > true if the provided listener is already registered. > > > > This has one significant drawback that all of Observable* are actually > > interfaces. Means we can only add hasListener as a defender method. The > > problem is with the default implementation. We cannot return anything > > meaningful, so we have to throw an UnsupportedOperationException. The > > problem is that this might blow up unexpectedly when some "older" > > Observable implementation is used. Also, it might be easy to miss when > > implementing the interface, since the IDE might not force you to > > implement it. > > > > So as an alternative solution, I propose adding something like: > > > > ensureListener(ListenerType listener) > > > > which would make sure the listener is on the list and if a listener is > > already present, the number of times listener is registered on the > > Observable will NOT grow after this call. > > > > 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? Why doing a remove and not simply check if the > listener has already been added? I, too, rely on the implementation detail that listeners are called in the order of registration. My code doesn't break as long as the internal JavaFX implementation keeps using Lists. I will just not use ensureListener() where the order matters. Tomas
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
On 01/22/2014 12:30 PM, Richard Bair 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. Unfortunately, this is not possible (without requiring users to cast). Most properties are exposed in API through ReadOnly*Property and *Property classes, which are abstract and do not have access to the listeners. Same with FX collections, an interface is returned from the API, not the base class. -Martin
Re: Monocle with VNC for Jenkins [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
Hi, I'm interested in headless testing, too. I tried to use StubToolkit for including TestFX tests in a headless build, but all I got was a CNFE. If anyone is interested to give me a hand on this, details can be found at http://stackoverflow.com/questions/21137039/how-to-use-stubtoolkit-instead-of-quantum-toolkit-for-my-javafx-application. As Tom explained, Monocle would provide another way for headless testing. Does it replace StubToolkit? Cheers, Uwe Tom Eugelink , 22/1/2014 8:46 AM: What also is very interesting is headless testing. Let me see if I'm getting this. Normally Jenkins would start a VNC server (xvnc), which provides some kind of graphics API against which an UI program can paint. JavaFX is not picking that up however. But, as I read it, in this case JavaFX starts its own VNC server, so it takes of everything itself. All one would need to do is specify the -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw And additionally a port to run the VNC server on (so multiple Jenkins jobs don't interfere). Am I correct? How can I test this (aka in which version is the VNC server available)? Tom
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Hi Randahl, I'm curious about an example where you would take advantage of the behavior where multiple addListener(listener) calls add the listener just once. Anyway, here [1] are helper classes InvalidationSubscriber and ChangeSubscriber that allow you to do that: InvalidationSubscriber subscriber = new InvalidationSubscriber(observable, listener); subscriber.subscribe(); // registers the listener subscriber.subscribe(); // no-op Cheers, Tomas [1] https://gist.github.com/TomasMikula/8557825 On Wed, Jan 22, 2014 at 11:23 AM, Randahl Fink Isaksen wrote: > Hi Martin > > While I agree your proposed solution would work, I still don’t understand > why JavaFX should keep on supporting duplicates in listener collections. > Can anyone come up with just 1 example of an application that might be > depending on having two listeners on the same Observable? E.g. this kind of > code: > > myObservable.addListener(myChangeListener); //add it > myObservable.addListener(myChangeListener); //add it again > > In what kind of situation would this sort of code make any sense? > > If we all feel confident that the presence of duplicates listeners is > always an error, I warmly recommend changing the API to be duplicate free. > > Yours > > Randahl > > > > > On 22 Jan 2014, at 11:07, Martin Sladecek > wrote: > > > Hi all, > > I would like to start discussion about an addition to API in Observable, > ObservableValue and all Observable collections. > > There were multiple requests for a way how to avoid duplicates in > listeners lists. The way RT-25613 solves this is that it introduces public > boolean hasListener(ListenerType listener) which would return true if the > provided listener is already registered. > > > > This has one significant drawback that all of Observable* are actually > interfaces. Means we can only add hasListener as a defender method. The > problem is with the default implementation. We cannot return anything > meaningful, so we have to throw an UnsupportedOperationException. The > problem is that this might blow up unexpectedly when some "older" > Observable implementation is used. Also, it might be easy to miss when > implementing the interface, since the IDE might not force you to implement > it. > > > > So as an alternative solution, I propose adding something like: > > > > ensureListener(ListenerType listener) > > > > which would make sure the listener is on the list and if a listener is > already present, the number of times listener is registered on the > Observable will NOT grow after this call. > > > > 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. > > > > What do you think? > > > > JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 > > > > -Martin > >
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
On 01/22/2014 12:30 PM, Richard Bair 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 :-( Actually even when you would rely on the order, in situations when you call ensureListener, you don't really know if the listener is already there. So you might really expect that listener would be added at this point as the last. It's just that will always be the outcome if the default implementation is used. -Martin
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
[...] > Actually even when you would rely on the order, in situations when you > call ensureListener, you don't really know if the listener is already > there. So you might really expect that listener would be added at this > point as the last. It's just that will always be the outcome if the > default implementation is used. It would be even worse if this would be different in none default implementations. Tom
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Hi Tomas Great idea! I can see how the InvalidationSubscriber idea would work – but it is just a concept right? There is no official API for this, right? Randahl On 22 Jan 2014, at 13:34, Tomas Mikula wrote: > Hi Randahl, > > I'm curious about an example where you would take advantage of the behavior > where multiple addListener(listener) calls add the listener just once. > > Anyway, here [1] are helper classes InvalidationSubscriber and > ChangeSubscriber that allow you to do that: > > InvalidationSubscriber subscriber = new InvalidationSubscriber(observable, > listener); > > subscriber.subscribe(); // registers the listener > subscriber.subscribe(); // no-op > > Cheers, > Tomas > > [1] https://gist.github.com/TomasMikula/8557825 > > On Wed, Jan 22, 2014 at 11:23 AM, Randahl Fink Isaksen > wrote: > Hi Martin > > While I agree your proposed solution would work, I still don’t understand why > JavaFX should keep on supporting duplicates in listener collections. Can > anyone come up with just 1 example of an application that might be depending > on having two listeners on the same Observable? E.g. this kind of code: > > myObservable.addListener(myChangeListener); //add it > myObservable.addListener(myChangeListener); //add it again > > In what kind of situation would this sort of code make any sense? > > If we all feel confident that the presence of duplicates listeners is always > an error, I warmly recommend changing the API to be duplicate free. > > Yours > > Randahl > > > > > On 22 Jan 2014, at 11:07, Martin Sladecek wrote: > > > Hi all, > > I would like to start discussion about an addition to API in Observable, > > ObservableValue and all Observable collections. > > There were multiple requests for a way how to avoid duplicates in listeners > > lists. The way RT-25613 solves this is that it introduces public boolean > > hasListener(ListenerType listener) which would return true if the provided > > listener is already registered. > > > > This has one significant drawback that all of Observable* are actually > > interfaces. Means we can only add hasListener as a defender method. The > > problem is with the default implementation. We cannot return anything > > meaningful, so we have to throw an UnsupportedOperationException. The > > problem is that this might blow up unexpectedly when some "older" > > Observable implementation is used. Also, it might be easy to miss when > > implementing the interface, since the IDE might not force you to implement > > it. > > > > So as an alternative solution, I propose adding something like: > > > > ensureListener(ListenerType listener) > > > > which would make sure the listener is on the list and if a listener is > > already present, the number of times listener is registered on the > > Observable will NOT grow after this call. > > > > 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. > > > > What do you think? > > > > JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 > > > > -Martin > >
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Hi Tomas About the example you request: Say you and I implemented a computer game with spaceships on screen, and lets imagine that these spaceships attacked in groups. Everytime a spaceship was added to a group, we wanted to listen to a property of that spaceship from that point in time and until eternity. Then, imagine we took out a spaceship from the group. We still wanted to listen to a property of the spaceship, but now it was no longer part of the group. Then, imagine we added the same spaceship to the same group once more. At this point, we don’t know if we have added the spaceship before, so when we write spaceship.someProperty.addListener(ourListener); we suddenly have ourListener added twice to the property. I know we can write removeListener(ourListener) followed by addListener(ourListener), and while that would work, I would much rather have the listener list ensure that there are no duplicates, since I believe that it is always a bug to register the same listener twice. Yours Randahl On 22 Jan 2014, at 13:34, Tomas Mikula wrote: > Hi Randahl, > > I'm curious about an example where you would take advantage of the behavior > where multiple addListener(listener) calls add the listener just once. > > Anyway, here [1] are helper classes InvalidationSubscriber and > ChangeSubscriber that allow you to do that: > > InvalidationSubscriber subscriber = new InvalidationSubscriber(observable, > listener); > > subscriber.subscribe(); // registers the listener > subscriber.subscribe(); // no-op > > Cheers, > Tomas > > [1] https://gist.github.com/TomasMikula/8557825 > > On Wed, Jan 22, 2014 at 11:23 AM, Randahl Fink Isaksen > wrote: > Hi Martin > > While I agree your proposed solution would work, I still don’t understand why > JavaFX should keep on supporting duplicates in listener collections. Can > anyone come up with just 1 example of an application that might be depending > on having two listeners on the same Observable? E.g. this kind of code: > > myObservable.addListener(myChangeListener); //add it > myObservable.addListener(myChangeListener); //add it again > > In what kind of situation would this sort of code make any sense? > > If we all feel confident that the presence of duplicates listeners is always > an error, I warmly recommend changing the API to be duplicate free. > > Yours > > Randahl > > > > > On 22 Jan 2014, at 11:07, Martin Sladecek wrote: > > > Hi all, > > I would like to start discussion about an addition to API in Observable, > > ObservableValue and all Observable collections. > > There were multiple requests for a way how to avoid duplicates in listeners > > lists. The way RT-25613 solves this is that it introduces public boolean > > hasListener(ListenerType listener) which would return true if the provided > > listener is already registered. > > > > This has one significant drawback that all of Observable* are actually > > interfaces. Means we can only add hasListener as a defender method. The > > problem is with the default implementation. We cannot return anything > > meaningful, so we have to throw an UnsupportedOperationException. The > > problem is that this might blow up unexpectedly when some "older" > > Observable implementation is used. Also, it might be easy to miss when > > implementing the interface, since the IDE might not force you to implement > > it. > > > > So as an alternative solution, I propose adding something like: > > > > ensureListener(ListenerType listener) > > > > which would make sure the listener is on the list and if a listener is > > already present, the number of times listener is registered on the > > Observable will NOT grow after this call. > > > > 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. > > > > What do you think? > > > > JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 > > > > -Martin > >
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
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 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
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
There is no official API. You are free to copy-paste the code from the link I posted to your project. On Wed, Jan 22, 2014 at 1:59 PM, Randahl Fink Isaksen wrote: > Hi Tomas > > Great idea! I can see how the InvalidationSubscriber idea would work – but > it is just a concept right? There is no official API for this, right? > > Randahl > > > > > > On 22 Jan 2014, at 13:34, Tomas Mikula wrote: > > Hi Randahl, > > I'm curious about an example where you would take advantage of the > behavior where multiple addListener(listener) calls add the listener just > once. > > Anyway, here [1] are helper classes InvalidationSubscriber and > ChangeSubscriber that allow you to do that: > > InvalidationSubscriber subscriber = new InvalidationSubscriber(observable, > listener); > > subscriber.subscribe(); // registers the listener > subscriber.subscribe(); // no-op > > Cheers, > Tomas > > [1] https://gist.github.com/TomasMikula/8557825 > > On Wed, Jan 22, 2014 at 11:23 AM, Randahl Fink Isaksen > wrote: > >> Hi Martin >> >> While I agree your proposed solution would work, I still don’t understand >> why JavaFX should keep on supporting duplicates in listener collections. >> Can anyone come up with just 1 example of an application that might be >> depending on having two listeners on the same Observable? E.g. this kind of >> code: >> >> myObservable.addListener(myChangeListener); //add it >> myObservable.addListener(myChangeListener); //add it again >> >> In what kind of situation would this sort of code make any sense? >> >> If we all feel confident that the presence of duplicates listeners is >> always an error, I warmly recommend changing the API to be duplicate free. >> >> Yours >> >> Randahl >> >> >> >> >> On 22 Jan 2014, at 11:07, Martin Sladecek >> wrote: >> >> > Hi all, >> > I would like to start discussion about an addition to API in >> Observable, ObservableValue and all Observable collections. >> > There were multiple requests for a way how to avoid duplicates in >> listeners lists. The way RT-25613 solves this is that it introduces public >> boolean hasListener(ListenerType listener) which would return true if the >> provided listener is already registered. >> > >> > This has one significant drawback that all of Observable* are actually >> interfaces. Means we can only add hasListener as a defender method. The >> problem is with the default implementation. We cannot return anything >> meaningful, so we have to throw an UnsupportedOperationException. The >> problem is that this might blow up unexpectedly when some "older" >> Observable implementation is used. Also, it might be easy to miss when >> implementing the interface, since the IDE might not force you to implement >> it. >> > >> > So as an alternative solution, I propose adding something like: >> > >> > ensureListener(ListenerType listener) >> > >> > which would make sure the listener is on the list and if a listener is >> already present, the number of times listener is registered on the >> Observable will NOT grow after this call. >> > >> > 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. >> > >> > What do you think? >> > >> > JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 >> > >> > -Martin >> >> > >
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Thanks for an example. I imagined something analogous to your example, but the part I'm curious about is this "We still wanted to listen to a property of the spaceship, but now it was no longer part of the group." Why would you want to keep listening to that spaceship after removal from the group? Regards, Tomas On Wed, Jan 22, 2014 at 2:11 PM, Randahl Fink Isaksen wrote: > Hi Tomas > > About the example you request: Say you and I implemented a computer game > with spaceships on screen, and lets imagine that these spaceships attacked > in groups. Everytime a spaceship was added to a group, we wanted to listen > to a property of that spaceship from that point in time and until eternity. > Then, imagine we took out a spaceship from the group. We still wanted to > listen to a property of the spaceship, but now it was no longer part of the > group. Then, imagine we added the same spaceship to the same group once > more. At this point, we don’t know if we have added the spaceship before, > so when we write > > spaceship.someProperty.addListener(ourListener); > > we suddenly have ourListener added twice to the property. > > I know we can write removeListener(ourListener) followed by > addListener(ourListener), and while that would work, I would much rather > have the listener list ensure that there are no duplicates, since I believe > that it is always a bug to register the same listener twice. > > Yours > > Randahl > > > > On 22 Jan 2014, at 13:34, Tomas Mikula wrote: > > Hi Randahl, > > I'm curious about an example where you would take advantage of the > behavior where multiple addListener(listener) calls add the listener just > once. > > Anyway, here [1] are helper classes InvalidationSubscriber and > ChangeSubscriber that allow you to do that: > > InvalidationSubscriber subscriber = new InvalidationSubscriber(observable, > listener); > > subscriber.subscribe(); // registers the listener > subscriber.subscribe(); // no-op > > Cheers, > Tomas > > [1] https://gist.github.com/TomasMikula/8557825 > > On Wed, Jan 22, 2014 at 11:23 AM, Randahl Fink Isaksen > wrote: > >> Hi Martin >> >> While I agree your proposed solution would work, I still don’t understand >> why JavaFX should keep on supporting duplicates in listener collections. >> Can anyone come up with just 1 example of an application that might be >> depending on having two listeners on the same Observable? E.g. this kind of >> code: >> >> myObservable.addListener(myChangeListener); //add it >> myObservable.addListener(myChangeListener); //add it again >> >> In what kind of situation would this sort of code make any sense? >> >> If we all feel confident that the presence of duplicates listeners is >> always an error, I warmly recommend changing the API to be duplicate free. >> >> Yours >> >> Randahl >> >> >> >> >> On 22 Jan 2014, at 11:07, Martin Sladecek >> wrote: >> >> > Hi all, >> > I would like to start discussion about an addition to API in >> Observable, ObservableValue and all Observable collections. >> > There were multiple requests for a way how to avoid duplicates in >> listeners lists. The way RT-25613 solves this is that it introduces public >> boolean hasListener(ListenerType listener) which would return true if the >> provided listener is already registered. >> > >> > This has one significant drawback that all of Observable* are actually >> interfaces. Means we can only add hasListener as a defender method. The >> problem is with the default implementation. We cannot return anything >> meaningful, so we have to throw an UnsupportedOperationException. The >> problem is that this might blow up unexpectedly when some "older" >> Observable implementation is used. Also, it might be easy to miss when >> implementing the interface, since the IDE might not force you to implement >> it. >> > >> > So as an alternative solution, I propose adding something like: >> > >> > ensureListener(ListenerType listener) >> > >> > which would make sure the listener is on the list and if a listener is >> already present, the number of times listener is registered on the >> Observable will NOT grow after this call. >> > >> > 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. >> > >> > What do you think? >> > >> > JIRA link: https://javafx-jira.kenai.com/browse/RT-25613 >> > >> > -Martin >> >> > >
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
Well it is just an fictive example. But for instance, there could be game rules that required us to listen to the energyPoints of all spaceships that had ever been part of the group. Perhaps the group would dissolve if more than 10 spaceships that had ever been part of the group where shot down. There could be many reasons why, and I certainly don’t think JavaFX should keep us from avoiding duplicate listeners. Yours Randahl On 22 Jan 2014, at 14:29, Tomas Mikula wrote: > Thanks for an example. I imagined something analogous to your example, but > the part I'm curious about is this > > "We still wanted to listen to a property of the spaceship, but now it was no > longer part of the group." > > Why would you want to keep listening to that spaceship after removal from the > group? > > Regards, > Tomas > > > On Wed, Jan 22, 2014 at 2:11 PM, Randahl Fink Isaksen > wrote: > Hi Tomas > > About the example you request: Say you and I implemented a computer game with > spaceships on screen, and lets imagine that these spaceships attacked in > groups. Everytime a spaceship was added to a group, we wanted to listen to a > property of that spaceship from that point in time and until eternity. Then, > imagine we took out a spaceship from the group. We still wanted to listen to > a property of the spaceship, but now it was no longer part of the group. > Then, imagine we added the same spaceship to the same group once more. At > this point, we don’t know if we have added the spaceship before, so when we > write > > spaceship.someProperty.addListener(ourListener); > > we suddenly have ourListener added twice to the property. > > I know we can write removeListener(ourListener) followed by > addListener(ourListener), and while that would work, I would much rather have > the listener list ensure that there are no duplicates, since I believe that > it is always a bug to register the same listener twice. > > Yours > > Randahl > > > > On 22 Jan 2014, at 13:34, Tomas Mikula wrote: > >> Hi Randahl, >> >> I'm curious about an example where you would take advantage of the behavior >> where multiple addListener(listener) calls add the listener just once. >> >> Anyway, here [1] are helper classes InvalidationSubscriber and >> ChangeSubscriber that allow you to do that: >> >> InvalidationSubscriber subscriber = new InvalidationSubscriber(observable, >> listener); >> >> subscriber.subscribe(); // registers the listener >> subscriber.subscribe(); // no-op >> >> Cheers, >> Tomas >> >> [1] https://gist.github.com/TomasMikula/8557825 >> >> On Wed, Jan 22, 2014 at 11:23 AM, Randahl Fink Isaksen >> wrote: >> Hi Martin >> >> While I agree your proposed solution would work, I still don’t understand >> why JavaFX should keep on supporting duplicates in listener collections. Can >> anyone come up with just 1 example of an application that might be depending >> on having two listeners on the same Observable? E.g. this kind of code: >> >> myObservable.addListener(myChangeListener); //add it >> myObservable.addListener(myChangeListener); //add it again >> >> In what kind of situation would this sort of code make any sense? >> >> If we all feel confident that the presence of duplicates listeners is always >> an error, I warmly recommend changing the API to be duplicate free. >> >> Yours >> >> Randahl >> >> >> >> >> On 22 Jan 2014, at 11:07, Martin Sladecek wrote: >> >> > Hi all, >> > I would like to start discussion about an addition to API in Observable, >> > ObservableValue and all Observable collections. >> > There were multiple requests for a way how to avoid duplicates in >> > listeners lists. The way RT-25613 solves this is that it introduces public >> > boolean hasListener(ListenerType listener) which would return true if the >> > provided listener is already registered. >> > >> > This has one significant drawback that all of Observable* are actually >> > interfaces. Means we can only add hasListener as a defender method. The >> > problem is with the default implementation. We cannot return anything >> > meaningful, so we have to throw an UnsupportedOperationException. The >> > problem is that this might blow up unexpectedly when some "older" >> > Observable implementation is used. Also, it might be easy to miss when >> > implementing the interface, since the IDE might not force you to implement >> > it. >> > >> > So as an alternative solution, I propose adding something like: >> > >> > ensureListener(ListenerType listener) >> > >> > which would make sure the listener is on the list and if a listener is >> > already present, the number of times listener is registered on the >> > Observable will NOT grow after this call. >> > >> > The default implementation (for Observable) would look like this: >> > >> > public default void ensureListener(InvalidationListener listener) { >> >removeListener(listener); >> >addListener(listener); >> > } >> > >> > subclas
[8u] Review Request: RT-35462,A controller with private fields gets broken when it's subclass is used as a fxml controller
Hi David, please review: http://cr.openjdk.java.net/~msladecek/rt-35462/webrev https://javafx-jira.kenai.com/browse/RT-35462 Thanks, -Martin
Re: Monocle with VNC for Jenkins [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
Hi Tom, You have it right. Currently the VNC server is always running on port 5901, but feel free to open a JIRA to change that. If you want to test this today you need to build OpenJFX yourself (https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX). We don’t have snapshots of 8u20 on java.net yet, although I hope we will soon. Thanks, Daniel On Jan 22, 2014, at 9:41 AM, Tom Eugelink wrote: > > What also is very interesting is headless testing. Let me see if I'm getting > this. > > Normally Jenkins would start a VNC server (xvnc), which provides some kind of > graphics API against which an UI program can paint. JavaFX is not picking > that up however. > But, as I read it, in this case JavaFX starts its own VNC server, so it takes > of everything itself. All one would need to do is specify the > > -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw > > And additionally a port to run the VNC server on (so multiple Jenkins jobs > don't interfere). > > Am I correct? How can I test this (aka in which version is the VNC server > available)? > > Tom > >
Re: Monocle with VNC for Jenkins [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
Hi Uwe, On Jan 22, 2014, at 2:19 PM, Uwe Sander wrote: > Hi, > > I'm interested in headless testing, too. I tried to use StubToolkit for > including TestFX tests in a headless build, but all I got was a CNFE. If > anyone is interested to give me a hand on this, details can be found at > http://stackoverflow.com/questions/21137039/how-to-use-stubtoolkit-instead-of-quantum-toolkit-for-my-javafx-application. > > As Tom explained, Monocle would provide another way for headless testing. > Does it replace StubToolkit? Monocle uses the same Quantum toolkit that other JavaFX implementation use - not StubToolkit, which is only used in testing. As I see it, there is a place for tests using StubToolkit, and a place for tests using a real Toolkit implementation. For example, QuantumToolkit has a very specific threading model, but this is not enforced by StubToolkit. StubToolkit is useful for isolated tests of the upper parts of the JavaFX stack. For a real application you need to test on a real Toolkit, and headless Monocle is one way to do that. We have https://javafx-jira.kenai.com/browse/RT-35330 open on removing StubToolkit. I’m not convinced that is the right thing to do. https://javafx-jira.kenai.com/browse/RT-35396 would open up possibilities for a new class of automated test, without requiring us to rewrite existing tests that use StubToolkit. Thanks, Daniel > > Cheers, > Uwe > > > > > Tom Eugelink , 22/1/2014 8:46 AM: > > What also is very interesting is headless testing. Let me see if I'm getting > this. > > Normally Jenkins would start a VNC server (xvnc), which provides some kind of > graphics API against which an UI program can paint. JavaFX is not picking > that up however. > But, as I read it, in this case JavaFX starts its own VNC server, so it takes > of everything itself. All one would need to do is specify the > > -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw > > And additionally a port to run the VNC server on (so multiple Jenkins jobs > don't interfere). > > Am I correct? How can I test this (aka in which version is the VNC server > available)? > > Tom > >
Re: Monocle with VNC for Jenkins [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
https://javafx-jira.kenai.com/browse/RT-35473 On 2014-1-22 14:41, Daniel Blaukopf wrote: Hi Tom, You have it right. Currently the VNC server is always running on port 5901, but feel free to open a JIRA to change that. If you want to test this today you need to build OpenJFX yourself (https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX). We don’t have snapshots of 8u20 on java.net yet, although I hope we will soon. Thanks, Daniel On Jan 22, 2014, at 9:41 AM, Tom Eugelink wrote: What also is very interesting is headless testing. Let me see if I'm getting this. Normally Jenkins would start a VNC server (xvnc), which provides some kind of graphics API against which an UI program can paint. JavaFX is not picking that up however. But, as I read it, in this case JavaFX starts its own VNC server, so it takes of everything itself. All one would need to do is specify the -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw And additionally a port to run the VNC server on (so multiple Jenkins jobs don't interfere). Am I correct? How can I test this (aka in which version is the VNC server available)? Tom
Re: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
Thanks John! I agree that in an IoT environment where you can have many devices, a central gateway and a fast local network, a solution based on remote display could work well. Daniel On Jan 22, 2014, at 1:07 AM, John Smith wrote: > Monocle is a very interesting and exciting development for the JavaFX team. > > I think that it is an avenue of approach which may help enable the > development of various innovative solutions, both in providing access to > JavaFX applications through traditional web UIs or providing remote GUI > access to myriad small devices which make up the Internet of Things. > > Ø Since WebSockets are part of Java EE I don't think this is something that > could be part of the standard JavaFX build > > Yes, I agree. There are some excellent existing WebSocket solutions for > Java, such as Tyrus https://tyrus.java.net/ and Kaazing. Though the > WebSocket protocol is simple to users, there are many tricky pitfalls in > creating a robust WebSocket server, so using those complete and well-tested > solutions is the best route. As the client app would actually be installed > on the server much like a normal JEE app, using a standard JEE lib is > perfectly appropriate I think. The tricky part (at least for me) would be to > take the VNC (or OpenGL) commands and tunnel them through a WebSocket system. > > Anyway, something to think about in my spare time. > > Thanks a lot for the replies and posting to the list Daniel. > > John > > From: Daniel Blaukopf [mailto:daniel.blauk...@oracle.com] > Sent: Tuesday, January 21, 2014 2:45 PM > To: John Smith; openjfx-dev@openjdk.java.net > Subject: Re: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] > Provide a VNC back-end] > > Hi John, > > On 01/22/2014 12:24 AM, John Smith wrote: > Would it be possible to develop a web based VNC client rendering to HTML > canvas that connects to the Monocle VNC server over WebSockets such as that > discussed in Kanaka’s answer here: > http://stackoverflow.com/a/3902817/1155209? > > I’m just interested in the feasibility of the approach as a basis for future > development of a potential 3rd party JavaFX app deployment solution outside > of JavaFX core. > I understand that this is probably not the primary reason the Monocle VNC > work was implemented, but I’m curious if it could be repurposed for this > mechanism. > Essentially, my goal here is to enable AppStreaming JavaFX > http://aws.amazon.com/appstream/ without requiring a proprietary amazon > solution. > > In your opinion, would such a solution be a feasible basis for developing a > distribution mechanism for JavaFX applications which does not require > anything on the client outside of an HTML5 compliant browser? > > It would absolutely be feasible, although the lag would probably be annoying. > Since WebSockets are part of Java EE I don't think this is something that > could be part of the standard JavaFX build, but Monocle allows for pluggable > screen implementations and it shouldn't be much work to modify VNCScreen.java > to do this. Alternatively we could put just enough of an implementation of > WebSockets in VNCScreen to be able to talk to the browser directly. > Fromhttp://www.websocket.org/aboutwebsocket.html the protocol doesn't look > complicated. Unless you need a secure authenticated connection of course, in > which case the answer would have to be Java EE. > > However, what would be 100x better in terms of perfomance would be to stream > the OpenGL commands to a WebGL client. We'd still have the lag though. We did > an experiment for a few days last month in the JavaFX team with marshalling > up OpenGL calls into a stream and sending them down the wire to a client > doing the rendering on another device, and the performance looked promising. > A bit like http://sourceforge.net/projects/virtualgl/, but without the video > stream. > > Thanks, > Daniel > > > Thanks, > John > > From: Daniel Blaukopf [mailto:daniel.blauk...@oracle.com] > Sent: Tuesday, January 21, 2014 12:53 PM > To: John Smith; openjfx-dev@openjdk.java.net > Subject: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] > Provide a VNC back-end] > > Hi John, > > This is a mostly complete implementation of Glass that instead of rendering > to the screen, renders to an offscreen buffer and serves the buffer up to > clients using the RFB protocol. So you should be able to connect to it with > most VNC clients, although I haven't been able to get it to work with desktop > sharing on the Mac. You can also provide mouse input to JavaFX using the VNC > client. > > To use (BTW, this is noted in the JIRA > https://javafx-jira.kenai.com/browse/RT-35441): > > Run with: -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw > > Connect with a VNC client to port 5901. I used TigerVNC > (http://sourceforge.net/projects/tigervnc/files/) since the OS X desktop > sharing c
hg: openjfx/8u-dev/rt: RT-35443 Provide a headless glass implementation integrated with our JUnit tests
Changeset: aa08f837ac40 Author:Daniel Blaukopf Date: 2014-01-22 15:49 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/aa08f837ac40 RT-35443 Provide a headless glass implementation integrated with our JUnit tests Reviewed-by: snortho, anthony ! build.gradle
Re: Monocle with VNC for Jenkins
Thanks for your answer, Daniel. If there's still a use case for StubToolkit, I'd like to know why I get a CNFE when I'm trying to use it in a simple JavaFX application (see the link in my previous message). Has anyone succeeded in building and using it (outside Oracle)? Cheers, Uwe Daniel Blaukopf , 22/1/2014 2:49 PM: Hi Uwe, On Jan 22, 2014, at 2:19 PM, Uwe Sander wrote: > Hi, > > I'm interested in headless testing, too. I tried to use StubToolkit for > including TestFX tests in a headless build, but all I got was a CNFE. If > anyone is interested to give me a hand on this, details can be found at > http://stackoverflow.com/questions/21137039/how-to-use-stubtoolkit-instead-of-quantum-toolkit-for-my-javafx-application. > > > As Tom explained, Monocle would provide another way for headless testing. > Does it replace StubToolkit? Monocle uses the same Quantum toolkit that other JavaFX implementation use - not StubToolkit, which is only used in testing. As I see it, there is a place for tests using StubToolkit, and a place for tests using a real Toolkit implementation. For example, QuantumToolkit has a very specific threading model, but this is not enforced by StubToolkit. StubToolkit is useful for isolated tests of the upper parts of the JavaFX stack. For a real application you need to test on a real Toolkit, and headless Monocle is one way to do that. We have https://javafx-jira.kenai.com/browse/RT-35330 open on removing StubToolkit. I’m not convinced that is the right thing to do. https://javafx-jira.kenai.com/browse/RT-35396 would open up possibilities for a new class of automated test, without requiring us to rewrite existing tests that use StubToolkit. Thanks, Daniel > > Cheers, > Uwe > > > > > Tom Eugelink , 22/1/2014 8:46 AM: > > What also is very interesting is headless testing. Let me see if I'm getting > this. > > Normally Jenkins would start a VNC server (xvnc), which provides some kind of > graphics API against which an UI program can paint. JavaFX is not picking > that up however. > But, as I read it, in this case JavaFX starts its own VNC server, so it takes > of everything itself. All one would need to do is specify the > > -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw > > And additionally a port to run the VNC server on (so multiple Jenkins jobs > don't interfere). > > Am I correct? How can I test this (aka in which version is the VNC server > available)? > > Tom > >
Re: Monocle with VNC for Jenkins
There is a StubToolkit. It is not part of the jar that is shipped with the JDK. You will need to build JFX and test against your build. https://javafx-jira.kenai.com/browse/RT-35010 Steve On 2014-01-22 11:14 AM, Uwe Sander wrote: Hi Steve, Thanks for your answer. Let me ask another question: how would you do headless testing in JFX 7? There's no Monocle, but I was under the impression there's a StubToolkit? Uwe Stephen F Northover , 22/1/2014 5:04 PM: I would like to see StubToolkit go. Why would you ever want to test code in a vastly different environment where the threading model is not enforced? Why would you want to headless implementations to test against instead of one? Having said all that, pragmatic may force us to have two. Steve On 2014-01-22 10:40 AM, Uwe Sander wrote: > Thanks for your answer, Daniel. > > If there's still a use case for StubToolkit, I'd like to know why I get a CNFE when I'm trying to use it in a simple JavaFX application (see the link in my previous message). Has anyone succeeded in building and using it (outside Oracle)? > > Cheers, > Uwe > > > > > Daniel Blaukopf mailto:daniel.blauk...@oracle.com>> , 22/1/2014 2:49 PM: > Hi Uwe, > > On Jan 22, 2014, at 2:19 PM, Uwe Sander mailto:usan...@tesis.de>> wrote: > >> Hi, >> >> I'm interested in headless testing, too. I tried to use StubToolkit for including TestFX tests in a headless build, but all I got was a CNFE. If anyone is interested to give me a hand on this, details can be found at http://stackoverflow.com/questions/21137039/how-to-use-stubtoolkit-instead-of-quantum-toolkit-for-my-javafx-application. >> >> As Tom explained, Monocle would provide another way for headless testing. Does it replace StubToolkit? > Monocle uses the same Quantum toolkit that other JavaFX implementation use - not StubToolkit, which is only used in testing. > > As I see it, there is a place for tests using StubToolkit, and a place for tests using a real Toolkit implementation. For example, QuantumToolkit has a very specific threading model, but this is not enforced by StubToolkit. StubToolkit is useful for isolated tests of the upper parts of the JavaFX stack. For a real application you need to test on a real Toolkit, and headless Monocle is one way to do that. > > We have https://javafx-jira.kenai.com/browse/RT-35330 open on removing StubToolkit. I’m not convinced that is the right thing to do. https://javafx-jira.kenai.com/browse/RT-35396 would open up possibilities for a new class of automated test, without requiring us to rewrite existing tests that use StubToolkit. > > Thanks, > Daniel > >> >> Cheers, >> Uwe >> >> >> >> >> Tom Eugelink mailto:t...@tbee.org>> , 22/1/2014 8:46 AM: >> >> What also is very interesting is headless testing. Let me see if I'm getting this. >> >> Normally Jenkins would start a VNC server (xvnc), which provides some kind of graphics API against which an UI program can paint. JavaFX is not picking that up however. >> But, as I read it, in this case JavaFX starts its own VNC server, so it takes of everything itself. All one would need to do is specify the >> >> -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw >> >> And additionally a port to run the VNC server on (so multiple Jenkins jobs don't interfere). >> >> Am I correct? How can I test this (aka in which version is the VNC server available)? >> >> Tom >> >> >
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
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 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
Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
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 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 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 >
hg: openjfx/8u-dev/rt: Initial push for RT-35243 - prism should use Monocle's platform detection code. Creates a new prism es2 port (prism-es-monocle) which uses the monocle port of glass. Note that i
Changeset: 2e23e1f2b922 Author:lisa.se...@oracle.com Date: 2014-01-22 13:04 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2e23e1f2b922 Initial push for RT-35243 - prism should use Monocle's platform detection code. Creates a new prism es2 port (prism-es-monocle) which uses the monocle port of glass. Note that it will not be selected on any platform by default; it requires a command line switch -Djavafx.platform=monocle -Dembedded=monocle. Not fully functional yet; currently falls back to software rendering partway through initialization. Reviewed by snorthov, dblaukopf ! .idea/codeStyleSettings.xml ! buildSrc/armv6sf.gradle ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NativeScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/FBDevScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxSystem.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/omap/OMAPScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/x11/X11Screen.java ! modules/graphics/src/main/java/com/sun/prism/es2/ES2Pipeline.java ! modules/graphics/src/main/java/com/sun/prism/es2/GLFactory.java + modules/graphics/src/main/java/com/sun/prism/es2/MonocleGLContext.java + modules/graphics/src/main/java/com/sun/prism/es2/MonocleGLDrawable.java + modules/graphics/src/main/java/com/sun/prism/es2/MonocleGLFactory.java + modules/graphics/src/main/java/com/sun/prism/es2/MonocleGLPixelFormat.java + modules/graphics/src/main/native-glass/monocle/EGL.c + modules/graphics/src/main/native-prism-es2/monocle/MonocleGLContext.c + modules/graphics/src/main/native-prism-es2/monocle/MonocleGLDrawable.c + modules/graphics/src/main/native-prism-es2/monocle/MonocleGLFactory.c + modules/graphics/src/main/native-prism-es2/monocle/MonoclePixelFormat.c + modules/graphics/src/main/native-prism-es2/monocle/eglUtils.c + modules/graphics/src/main/native-prism-es2/monocle/eglUtils.h
hg: openjfx/8/master/rt: Added tag 8.0-b125 for changeset 3e1c456afa4c
Changeset: a9a442d98304 Author:hudson Date: 2014-01-22 08:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a9a442d98304 Added tag 8.0-b125 for changeset 3e1c456afa4c ! .hgtags
hg: openjfx/8u-dev/rt: RT-35487: build files should use IS_COMPILE_PANGO (instead of COMPILE_PANGO)
Changeset: f7e4bebcf795 Author:Felipe Heidrich Date: 2014-01-22 07:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f7e4bebcf795 RT-35487: build files should use IS_COMPILE_PANGO (instead of COMPILE_PANGO) ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/linux.gradle
hg: openjfx/8u-dev/rt: Fix RT-25249: ImageInput effect not updated when WritableImage is updated
Changeset: cbe1008fbea3 Author:flar Date: 2014-01-22 11:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cbe1008fbea3 Fix RT-25249: ImageInput effect not updated when WritableImage is updated Reviewed by Felipe and Chien ! modules/graphics/src/main/java/javafx/scene/effect/ImageInput.java
hg: openjfx/8u-dev/rt: Fix RT-33294: Canas PixelWriter can be very slow
Changeset: 3943d4344924 Author:flar Date: 2014-01-22 13:39 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3943d4344924 Fix RT-33294: Canas PixelWriter can be very slow Reviewed by Felipe and Chien ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/GrowableDataBuffer.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGCanvas.java
Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
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 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 Bairwrote: 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
Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
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 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 Bairwrote: >>> 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 >
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. Steve 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 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 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 Bairwrote: 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
hg: openjfx/8u-dev/rt: RT-35141: [TableView] TableView Column Reordering sometimes fails and often doesn't match the visual feedback
Changeset: a46ffa89a080 Author:jgiles Date: 2014-01-23 12:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a46ffa89a080 RT-35141: [TableView] TableView Column Reordering sometimes fails and often doesn't match the visual feedback ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java + modules/controls/src/test/java/com/sun/javafx/scene/control/skin/TableColumnHeaderRetriever.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java