Adding GStreamer plugins

[Michael Berry]

Hi all,

I've managed to clone and build OpenJFX successfully, and am now in the
process of trying to see how feasible it would be to add support for other
media formats. As a first port of call I'm attempting to see if I can get
the framework accepting the Matroska plugin, but seem to be coming a bit
unstuck on the native side of things (including the plugin with GStreamer.)
I've made the relevant modifications on the Java side of things to persuade
the platform to accept MKV files and pass them down to the GStreamer layer,
and that compiles and runs without any issues.

However, I'm not sure if I'm going about including the matroska plugin in
the right way - I've currently done the following:

 - Downloaded the latest version of the plugins from here (
http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the
matroska one to the modules/media/src/main/native/gstreamer/plugins/
folder, as well as the
modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/
folder (I'm unsure of this - should I add it to both these folders?).

 - Added all the C files from the first folder mentioned above to the
plugins.vcxproj file

 - Added the relevant files and directory to Makefile.gstplugins

 - Called the additional relevant plugin_init() function in
gstplugins-lite.c

However, after the above I still get the same result having touched none of
the native code, that being that GSTMediaPlayer throws a MediaException
with flag 257, which seems to mean it couldn't create the required media
from the given location.

So at this point I'm a bit stuck really - of course, the whole task may be
much more complicated than I'm assuming it should be. I'm not even sure if
the default "gradle sdk" task is actually reflecting the changes I've made
- certainly gstreamer-lite.dll seems to be exactly the same size as before,
though I'm unsure if the additional plugin is meant to be embedded in this
file or not. I'm experienced with Java but much less so with C++, and
completely new to gradle (as of yesterday.)

Is there anything obvious I'm not doing correctly, and if so would someone
be kind enough to give me a bit of a nudge in the right direction?

Many thanks,

Michael

Blog post: Trigger processing after a period of inactivity

[Tomas Mikula]

Hi all,

I just want to quickly inform that I have a post on how to defer
processing of user input until the user has been inactive for a
certain amount of time.

http://tomasmikula.github.io/blog/2014/03/22/trigger-processing-after-a-period-of-inactivity.html

Best regards,
Tomas

Re: LNK1123: failure during conversion to COFF when building under windows

[Kevin Rushforth]

Glad this solved your problem. I added "SP1" to the Wiki page.

-- Kevin


Michael Berry wrote:

Hi Kevin,

Many thanks for that - that has solved the problem! Perhaps the wiki 
page  
should be updated to note that SP1 should be installed as well as 
vanilla VS2010? I would do it myself, but don't have the privileges.


Thanks,

Michael


On 22 March 2014 14:46, Kevin Rushforth > wrote:


Do you have VS 2010 Service Pack 1? I've seen this failure on
machines that don't have SP1 installed.

-- Kevin



Michael Berry wrote:

Hi,

I'm currently trying to build OpenJFX from source on Windows - I've
followed the instructions on the build page and have Visual Studio 2010,
the June 2010 directx sdk, cygwin and its relevant modules installed.
However, when building it fails at the buildJavaFXPackage task (output
below.)

I'm not sure if those warnings are normal or not, but they definitely look
suspicious. It seems the actual error that's stopping things is the "fatal
error LNK1123: failure during conversion to COFF: file invalid or corrupt"
line, though all I've found searching around for that error is that
"incremental:off" should be set to avoid it, which it already is in the
gradle task.

Any ideas?

Thanks,

Michael

:fxml:jar
:fxml:assemble
:fxpackager:buildJavaFXPackager
javafxpackager.cpp

C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258)
: warning C4018: '<' : signed/unsigned mismatch

C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269)
: warning C4018: '<' : signed/unsigned mismatch

C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286)
: warning C4018: '<' : signed/unsigned mismatch

C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426)
: warning C4996: 'getenv': This function or variable may be unsafe.
Consider using _dupenv_s instead. To disable deprecation,use
_CRT_SECURE_NO_WARNINGS. See online help for details.
C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal
error LNK1123: failure during conversion to COFF: file invalid or corrupt
:fxpackager:buildJavaFXPackager FAILED

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817

* What went wrong:
Execution failed for task ':fxpackager:buildJavaFXPackager'.
  

Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio


10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123
  

Re: LNK1123: failure during conversion to COFF when building under windows

[Michael Berry]

Hi Kevin,

Many thanks for that - that has solved the problem! Perhaps the wiki
pageshould
be updated to note that SP1 should be installed as well as vanilla
VS2010? I would do it myself, but don't have the privileges.

Thanks,

Michael


On 22 March 2014 14:46, Kevin Rushforth  wrote:

>  Do you have VS 2010 Service Pack 1? I've seen this failure on machines
> that don't have SP1 installed.
>
> -- Kevin
>
>
>
> Michael Berry wrote:
>
> Hi,
>
> I'm currently trying to build OpenJFX from source on Windows - I've
> followed the instructions on the build page and have Visual Studio 2010,
> the June 2010 directx sdk, cygwin and its relevant modules installed.
> However, when building it fails at the buildJavaFXPackage task (output
> below.)
>
> I'm not sure if those warnings are normal or not, but they definitely look
> suspicious. It seems the actual error that's stopping things is the "fatal
> error LNK1123: failure during conversion to COFF: file invalid or corrupt"
> line, though all I've found searching around for that error is that
> "incremental:off" should be set to avoid it, which it already is in the
> gradle task.
>
> Any ideas?
>
> Thanks,
>
> Michael
>
> :fxml:jar
> :fxml:assemble
> :fxpackager:buildJavaFXPackager
> javafxpackager.cpp
> C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258)
> : warning C4018: '<' : signed/unsigned mismatch
> C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269)
> : warning C4018: '<' : signed/unsigned mismatch
> C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286)
> : warning C4018: '<' : signed/unsigned mismatch
> C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426)
> : warning C4996: 'getenv': This function or variable may be unsafe.
> Consider using _dupenv_s instead. To disable deprecation,use
> _CRT_SECURE_NO_WARNINGS. See online help for details.
> C:/Program Files (x86)/Microsoft Visual Studio
> 10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal
> error LNK1123: failure during conversion to COFF: file invalid or corrupt
> :fxpackager:buildJavaFXPackager FAILED
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817
>
> * What went wrong:
> Execution failed for task ':fxpackager:buildJavaFXPackager'.
>
>
>  Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio
>
>
>  10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123
>
>
>

Re: *PropertyBase vs Simple*Property

[Tomas Mikula]

On Sat, Mar 22, 2014 at 4:41 PM, Tom Schindl
 wrote:
> Ah i missed you passing them to the constructor.
>
> Still i don't see this as much an improvement because we still create a vast 
> amount of anon inner classes.

Sure, I just wanted to get the baseline for comparison right.

Tomas

>
> Tom
>
> Von meinem iPhone gesendet
>
>> Am 22.03.2014 um 16:23 schrieb Tom Schindl :
>>
>> Why not i expect the property to be fully initialize so this would be a 
>> breaking change in behavior.
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>>> Am 22.03.2014 um 14:54 schrieb Tomas Mikula :
>>>
>>> On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
>>>  wrote:
 Hi Richard,

 Coming back to this old thread and now that we are using lamdas all over
 I guess we could take one more look into that.

 I've prototyped an initial version by introducing a new internal type
 named InvalidatedSimpleObjectProperty (not the best name ever!) - see
 code pasted below.

 And now one can write code like this:

>   public final ObjectProperty viewportProperty() {
>   if (viewport == null) {
>   viewport = new InvalidatedSimpleObjectProperty<>(this, 
> "viewport", (o) -> {
> invalidateWidthHeight();
>   impl_markDirty(DirtyBits.NODE_VIEWPORT);
>   impl_geomChanged();
>   } );
>   }
>   return viewport;
>   }

 instead of

>   public final ObjectProperty viewportProperty() {
>   if (viewport == null) {
>   viewport = new ObjectPropertyBase() {
>
>   @Override
>   protected void invalidated() {
>   invalidateWidthHeight();
>   impl_markDirty(DirtyBits.NODE_VIEWPORT);
>   impl_geomChanged();
>   }
>
>   @Override
>   public Object getBean() {
>   return ImageView.this;
>   }
>
>   @Override
>   public String getName() {
>   return "viewport";
>   }
>   };
>   }
>   return viewport;
>   }
>>>
>>> Nice idea. Just to get the comparison to status quo more fair, you
>>> don't need to override getBean() and getName() methods:
>>>
>>> public final ObjectProperty viewportProperty() {
>>>   if (viewport == null) {
>>>   viewport = new SimpleObjectProperty(this, "viewport") {
>>>
>>>   @Override
>>>   protected void invalidated() {
>>>   invalidateWidthHeight();
>>>   impl_markDirty(DirtyBits.NODE_VIEWPORT);
>>>   impl_geomChanged();
>>>   }
>>>   };
>>>   }
>>>   return viewport;
>>> }
>>>
>>> Regards,
>>> Tomas
>>>

 Which allows us to get rid of most of the ObjectPropertyBase sublcasses.

 Tom


> package com.sun.javafx.property;
>
> import java.util.function.Consumer;
>
> import javafx.beans.property.SimpleObjectProperty;
>
> public final class InvalidatedSimpleObjectProperty extends 
> SimpleObjectProperty {
> private final Consumer> 
> invalidationConsumer;
>
>   /**
>* The constructor of {@code ObjectProperty}
>*
>* @param initialValue
>*the initial value of the wrapped value
>* @param invalidationConsumer
>*  the consumer to be called when the bean is 
> invalidated
>*/
>   public InvalidatedSimpleObjectProperty(T initialValue, final 
> Consumer> invalidationConsumer) {
>   super(initialValue);
>   if( invalidationConsumer == null ) {
> throw new IllegalArgumentException("Consumer can not be 
> null");
>   }
>   this.invalidationConsumer = invalidationConsumer;
>   }
>
>   /**
>* The constructor of {@code ObjectProperty}
>*
>* @param bean
>*the bean of this {@code ObjectProperty}
>* @param name
>*the name of this {@code ObjectProperty}
>* @param invalidationConsumer
>*  the consumer to be called when the bean is 
> invalidated
>*/
>   public InvalidatedSimpleObjectProperty(Object bean, String name, final 
> Consumer> invalidationConsumer) {
>  super(bean, name);
>  if( invalidationConsumer == null ) {
> throw new IllegalArgumentException("Consumer can not be 
> null");
>  }
>  this.invalidationConsumer = invalidationConsumer;
>   }
>
>   /**
>* The constructor of {@code ObjectProperty}
>*
>* @param bean
>*the bean of this {@code ObjectProperty}
>* @param name
>*the name of this {@code ObjectProperty}
>* @

Re: Ability to decorate ChangeListener

[Tomas Mikula]

On Sat, Mar 22, 2014 at 4:11 PM, Mario Ivankovits  wrote:
> Probably you avoid the map, but it requires to decorate the listener again,
> right?

Right. For a pair of addListener-removeListener calls, you have 2
decorations instead of 1. I usually think of the costs in asymptotic
terms: if 1 decoration is cheap, then 2 decorations are cheap as well.
Or, if we can afford n decorations, then we can probably afford 2n
decorations. I know this is not quite true in real world (200ms is not
the same as 100ms), but is a good way to think about complexity.

> If you think about the tons of observable values and add/removeListener
> operations in an tree view when scrolling it might get costly and put
> pressure on the GC.

removeListener creates one extra short-lived object. I don't know if
it is still true for the current garbage collector in Hotspot, but a
while ago I read that creating a lot of cheap short-lived objects is
fine for the GC.

Regards,
Tomas

>
> Anyway, I will be more than happy to assist with a cleaner solution by
> introduction an interface like DecoratedChangeListener which provides a
> special .equalsChangeListener(ChangeListener other) method.
>
>
> Am 22.03.2014 um 15:55 schrieb Tomas Mikula :
>
> Hi Mario,
>
> even if your proposal gets accepted, you would still depend on an
> implementation detail of JavaFX, which is always good to avoid.
>
> To sum up, my second proposal compared to your current solution:
>
> (+) your equals() stays symmetric;
> (+) no need for an extra Map of listeners.
>
> My second proposal compared to your desired solution if your proposal
> is accepted:
>
> (+) your equals() stays symmetric;
> (+) you don't depend on an implementation detail in JavaFX.
>
> Best,
> Tomas
>
> On Sat, Mar 22, 2014 at 3:47 PM, Mario Ivankovits 
> wrote:
>
> The only thing which I ask for is to flip this „if" in the *ExpressionHelper
> classes:
> So, JavaFX does not break anything and it is up to the app developer to take
> the risk or not.
>
>   if (listener.equals(changeListeners[index])) {
>
> If we flip this to
>
>   if (changeListeners[index].equals(listener))
>
>
>
>
> Am 22.03.2014 um 15:42 schrieb Kevin Rushforth :
>
> If you are talking about a change to the JavaFX API, we are not likely to
> accept such a change if it breaks the contract of equals() or hashcode(). In
> your own app it may not matter, but it is dangerous to assume it won't
> matter to anyone. Martin owns the core libraries and can comment further.
>
> -- Kevin
>
>
> Mario Ivankovits wrote:
>
> Hi Thomas!
>
> Thanks for your input. Because I want to decorated listeners added by JavaFX
> core I can not use the sub/unsub pattern.
> Your second proposal is almost what I do right now. In removeListener I
> consult a map where the decorated listeners and their undecorated one lives.
>
> Regarding the symmetric doubts. Such listeners will always be removed by
> passing in the undecorated object to removeListener.
> They should act like a transparent proxy.
>
> Even if this breaks the equals paradigm, in this special case I can
> perfectly live with an equals/hashCode implementation like this below.
> It won’t break your app; as long as both objects do not live in the same
> HashSet/Map …. for sure - but why should they?
>
>@Override
>public boolean equals(Object obj)
>{
>return obj == delegate; // && this == obj
>}
>
>@Override
>public int hashCode()
>{
>return delegate.hashCode();
>}
>
>
> Regards,
> Mario
>
>
> Am 22.03.2014 um 14:22 schrieb Tomas Mikula :
>
>
>
> A simpler and more universal solution is to also override removeListener:
>
> public void removeListener(ChangeListener listener) {
>   super.removeListener(decorated(listener));
> }
>
> And the equals() method on decorated listeners only compares the
> delegates (thus is symmetric).
>
> Regards,
> Tomas
>
>
> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula 
> wrote:
>
>
> The suspicious thing about your solution is that your smart
> implementation of equals() is not symmetric.
>
> In case the observable value is visible only within your project, you
> could do this:
>
>   interface Subscription {
>   void unsubscribe();
>   }
>
>   class MyObservableValue implements ObservableValue {
>   public Subscription subscribe(ChangeListener listener) {
>   ChangeListener decorated = decorate(listener);
>  addListener(decorated);
>  return () -> removeListener(decorated);
>   }
>   }
>
> and use subscribe()/unsubscribe() instead of addListener()/removeListener():
>
>   Subscription sub = observableValue.subscribe(listener);
>   // ...
>   sub.unsubscribe();
>
> Of course this is not possible if you need to pass the observable
> value to the outside world as ObservableValue.
>
> Regards,
> Tomas
>
> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits 
> wrote:
>
>
> Hi!
>
> In one of my ObservableValue implementations I do have the need to decorate
> ChangeList

Re: *PropertyBase vs Simple*Property

[Tom Schindl]

Ah i missed you passing them to the constructor.

Still i don't see this as much an improvement because we still create a vast 
amount of anon inner classes.

Tom

Von meinem iPhone gesendet

> Am 22.03.2014 um 16:23 schrieb Tom Schindl :
> 
> Why not i expect the property to be fully initialize so this would be a 
> breaking change in behavior.
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
>> Am 22.03.2014 um 14:54 schrieb Tomas Mikula :
>> 
>> On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
>>  wrote:
>>> Hi Richard,
>>> 
>>> Coming back to this old thread and now that we are using lamdas all over
>>> I guess we could take one more look into that.
>>> 
>>> I've prototyped an initial version by introducing a new internal type
>>> named InvalidatedSimpleObjectProperty (not the best name ever!) - see
>>> code pasted below.
>>> 
>>> And now one can write code like this:
>>> 
   public final ObjectProperty viewportProperty() {
   if (viewport == null) {
   viewport = new InvalidatedSimpleObjectProperty<>(this, 
 "viewport", (o) -> {
 invalidateWidthHeight();
   impl_markDirty(DirtyBits.NODE_VIEWPORT);
   impl_geomChanged();
   } );
   }
   return viewport;
   }
>>> 
>>> instead of
>>> 
   public final ObjectProperty viewportProperty() {
   if (viewport == null) {
   viewport = new ObjectPropertyBase() {
 
   @Override
   protected void invalidated() {
   invalidateWidthHeight();
   impl_markDirty(DirtyBits.NODE_VIEWPORT);
   impl_geomChanged();
   }
 
   @Override
   public Object getBean() {
   return ImageView.this;
   }
 
   @Override
   public String getName() {
   return "viewport";
   }
   };
   }
   return viewport;
   }
>> 
>> Nice idea. Just to get the comparison to status quo more fair, you
>> don't need to override getBean() and getName() methods:
>> 
>> public final ObjectProperty viewportProperty() {
>>   if (viewport == null) {
>>   viewport = new SimpleObjectProperty(this, "viewport") {
>> 
>>   @Override
>>   protected void invalidated() {
>>   invalidateWidthHeight();
>>   impl_markDirty(DirtyBits.NODE_VIEWPORT);
>>   impl_geomChanged();
>>   }
>>   };
>>   }
>>   return viewport;
>> }
>> 
>> Regards,
>> Tomas
>> 
>>> 
>>> Which allows us to get rid of most of the ObjectPropertyBase sublcasses.
>>> 
>>> Tom
>>> 
>>> 
 package com.sun.javafx.property;
 
 import java.util.function.Consumer;
 
 import javafx.beans.property.SimpleObjectProperty;
 
 public final class InvalidatedSimpleObjectProperty extends 
 SimpleObjectProperty {
 private final Consumer> 
 invalidationConsumer;
 
   /**
* The constructor of {@code ObjectProperty}
*
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
*  the consumer to be called when the bean is 
 invalidated
*/
   public InvalidatedSimpleObjectProperty(T initialValue, final 
 Consumer> invalidationConsumer) {
   super(initialValue);
   if( invalidationConsumer == null ) {
 throw new IllegalArgumentException("Consumer can not be null");
   }
   this.invalidationConsumer = invalidationConsumer;
   }
 
   /**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param invalidationConsumer
*  the consumer to be called when the bean is 
 invalidated
*/
   public InvalidatedSimpleObjectProperty(Object bean, String name, final 
 Consumer> invalidationConsumer) {
  super(bean, name);
  if( invalidationConsumer == null ) {
 throw new IllegalArgumentException("Consumer can not be null");
  }
  this.invalidationConsumer = invalidationConsumer;
   }
 
   /**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
*  the consumer to be called when the bean is 
 invalidated
*/
   public InvalidatedSimpleObjectProperty(

Re: *PropertyBase vs Simple*Property

[Tom Schindl]

Why not i expect the property to be fully initialize so this would be a 
breaking change in behavior.

Tom

Von meinem iPhone gesendet

> Am 22.03.2014 um 14:54 schrieb Tomas Mikula :
> 
> On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
>  wrote:
>> Hi Richard,
>> 
>> Coming back to this old thread and now that we are using lamdas all over
>> I guess we could take one more look into that.
>> 
>> I've prototyped an initial version by introducing a new internal type
>> named InvalidatedSimpleObjectProperty (not the best name ever!) - see
>> code pasted below.
>> 
>> And now one can write code like this:
>> 
>>>public final ObjectProperty viewportProperty() {
>>>if (viewport == null) {
>>>viewport = new InvalidatedSimpleObjectProperty<>(this, 
>>> "viewport", (o) -> {
>>>  invalidateWidthHeight();
>>>impl_markDirty(DirtyBits.NODE_VIEWPORT);
>>>impl_geomChanged();
>>>} );
>>>}
>>>return viewport;
>>>}
>> 
>> instead of
>> 
>>>public final ObjectProperty viewportProperty() {
>>>if (viewport == null) {
>>>viewport = new ObjectPropertyBase() {
>>> 
>>>@Override
>>>protected void invalidated() {
>>>invalidateWidthHeight();
>>>impl_markDirty(DirtyBits.NODE_VIEWPORT);
>>>impl_geomChanged();
>>>}
>>> 
>>>@Override
>>>public Object getBean() {
>>>return ImageView.this;
>>>}
>>> 
>>>@Override
>>>public String getName() {
>>>return "viewport";
>>>}
>>>};
>>>}
>>>return viewport;
>>>}
> 
> Nice idea. Just to get the comparison to status quo more fair, you
> don't need to override getBean() and getName() methods:
> 
> public final ObjectProperty viewportProperty() {
>if (viewport == null) {
>viewport = new SimpleObjectProperty(this, "viewport") {
> 
>@Override
>protected void invalidated() {
>invalidateWidthHeight();
>impl_markDirty(DirtyBits.NODE_VIEWPORT);
>impl_geomChanged();
>}
>};
>}
>return viewport;
> }
> 
> Regards,
> Tomas
> 
>> 
>> Which allows us to get rid of most of the ObjectPropertyBase sublcasses.
>> 
>> Tom
>> 
>> 
>>> package com.sun.javafx.property;
>>> 
>>> import java.util.function.Consumer;
>>> 
>>> import javafx.beans.property.SimpleObjectProperty;
>>> 
>>> public final class InvalidatedSimpleObjectProperty extends 
>>> SimpleObjectProperty {
>>>  private final Consumer> 
>>> invalidationConsumer;
>>> 
>>>/**
>>> * The constructor of {@code ObjectProperty}
>>> *
>>> * @param initialValue
>>> *the initial value of the wrapped value
>>> * @param invalidationConsumer
>>> *  the consumer to be called when the bean is 
>>> invalidated
>>> */
>>>public InvalidatedSimpleObjectProperty(T initialValue, final 
>>> Consumer> invalidationConsumer) {
>>>super(initialValue);
>>>if( invalidationConsumer == null ) {
>>>  throw new IllegalArgumentException("Consumer can not be null");
>>>}
>>>this.invalidationConsumer = invalidationConsumer;
>>>}
>>> 
>>>/**
>>> * The constructor of {@code ObjectProperty}
>>> *
>>> * @param bean
>>> *the bean of this {@code ObjectProperty}
>>> * @param name
>>> *the name of this {@code ObjectProperty}
>>> * @param invalidationConsumer
>>> *  the consumer to be called when the bean is 
>>> invalidated
>>> */
>>>public InvalidatedSimpleObjectProperty(Object bean, String name, final 
>>> Consumer> invalidationConsumer) {
>>>   super(bean, name);
>>>   if( invalidationConsumer == null ) {
>>>  throw new IllegalArgumentException("Consumer can not be null");
>>>   }
>>>   this.invalidationConsumer = invalidationConsumer;
>>>}
>>> 
>>>/**
>>> * The constructor of {@code ObjectProperty}
>>> *
>>> * @param bean
>>> *the bean of this {@code ObjectProperty}
>>> * @param name
>>> *the name of this {@code ObjectProperty}
>>> * @param initialValue
>>> *the initial value of the wrapped value
>>> * @param invalidationConsumer
>>> *  the consumer to be called when the bean is 
>>> invalidated
>>> */
>>>public InvalidatedSimpleObjectProperty(Object bean, String name, T 
>>> initialValue, final Consumer> 
>>> invalidationConsumer) {
>>>super(bean,name,initialValue);
>>>if( invalidationConsumer == null ) {
>>>  throw new IllegalArgumentException("Consumer can not be null");
>>>}
>>>this.invalidationConsumer

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

Probably you avoid the map, but it requires to decorate the listener again, 
right?
If you think about the tons of observable values and add/removeListener 
operations in an tree view when scrolling it might get costly and put pressure 
on the GC.

Anyway, I will be more than happy to assist with a cleaner solution by 
introduction an interface like DecoratedChangeListener which provides a special 
.equalsChangeListener(ChangeListener other) method.


Am 22.03.2014 um 15:55 schrieb Tomas Mikula 
mailto:tomas.mik...@gmail.com>>:

Hi Mario,

even if your proposal gets accepted, you would still depend on an
implementation detail of JavaFX, which is always good to avoid.

To sum up, my second proposal compared to your current solution:

(+) your equals() stays symmetric;
(+) no need for an extra Map of listeners.

My second proposal compared to your desired solution if your proposal
is accepted:

(+) your equals() stays symmetric;
(+) you don't depend on an implementation detail in JavaFX.

Best,
Tomas

On Sat, Mar 22, 2014 at 3:47 PM, Mario Ivankovits 
mailto:ma...@datenwort.at>> wrote:
The only thing which I ask for is to flip this „if" in the *ExpressionHelper
classes:
So, JavaFX does not break anything and it is up to the app developer to take
the risk or not.

  if (listener.equals(changeListeners[index])) {

If we flip this to

  if (changeListeners[index].equals(listener))




Am 22.03.2014 um 15:42 schrieb Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>>:

If you are talking about a change to the JavaFX API, we are not likely to
accept such a change if it breaks the contract of equals() or hashcode(). In
your own app it may not matter, but it is dangerous to assume it won't
matter to anyone. Martin owns the core libraries and can comment further.

-- Kevin


Mario Ivankovits wrote:

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I
consult a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can
perfectly live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same
HashSet/Map …. for sure - but why should they?

   @Override
   public boolean equals(Object obj)
   {
   return obj == delegate; // && this == obj
   }

   @Override
   public int hashCode()
   {
   return delegate.hashCode();
   }


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula 
mailto:tomas.mik...@gmail.com>>:



A simpler and more universal solution is to also override removeListener:

public void removeListener(ChangeListener listener) {
  super.removeListener(decorated(listener));
}

And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).

Regards,
Tomas


On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula 
mailto:tomas.mik...@gmail.com>>
wrote:


The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.

In case the observable value is visible only within your project, you
could do this:

  interface Subscription {
  void unsubscribe();
  }

  class MyObservableValue implements ObservableValue {
  public Subscription subscribe(ChangeListener listener) {
  ChangeListener decorated = decorate(listener);
 addListener(decorated);
 return () -> removeListener(decorated);
  }
  }

and use subscribe()/unsubscribe() instead of addListener()/removeListener():

  Subscription sub = observableValue.subscribe(listener);
  // ...
  sub.unsubscribe();

Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.

Regards,
Tomas

On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits 
mailto:ma...@datenwort.at>>
wrote:


Hi!

In one of my ObservableValue implementations I do have the need to decorate
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of
the original listener to the decorated one to being able to handle the
removal process of a listener. Because the outside World did not know that I
decorated the listener and the instance passed in to removeListener ist the
undecorated one.

We can make things easier with a small change in
ExpressionHelper.removeListener. When iterating through the listener list,
the listener passed in as argument to removeListener is asked if it is equal
to the one stored

  if (listener.equals(changeListeners[index])) {

If we flip this to

  if (changeListeners[index].equals(listener)) {

a listener decoration can be smart enough to not only check against

Re: Ability to decorate ChangeListener

[Tomas Mikula]

Hi Mario,

even if your proposal gets accepted, you would still depend on an
implementation detail of JavaFX, which is always good to avoid.

To sum up, my second proposal compared to your current solution:

(+) your equals() stays symmetric;
(+) no need for an extra Map of listeners.

My second proposal compared to your desired solution if your proposal
is accepted:

(+) your equals() stays symmetric;
(+) you don't depend on an implementation detail in JavaFX.

Best,
Tomas

On Sat, Mar 22, 2014 at 3:47 PM, Mario Ivankovits  wrote:
> The only thing which I ask for is to flip this „if" in the *ExpressionHelper
> classes:
> So, JavaFX does not break anything and it is up to the app developer to take
> the risk or not.
>
>if (listener.equals(changeListeners[index])) {
>
> If we flip this to
>
>if (changeListeners[index].equals(listener))
>
>
>
>
> Am 22.03.2014 um 15:42 schrieb Kevin Rushforth :
>
> If you are talking about a change to the JavaFX API, we are not likely to
> accept such a change if it breaks the contract of equals() or hashcode(). In
> your own app it may not matter, but it is dangerous to assume it won't
> matter to anyone. Martin owns the core libraries and can comment further.
>
> -- Kevin
>
>
> Mario Ivankovits wrote:
>
> Hi Thomas!
>
> Thanks for your input. Because I want to decorated listeners added by JavaFX
> core I can not use the sub/unsub pattern.
> Your second proposal is almost what I do right now. In removeListener I
> consult a map where the decorated listeners and their undecorated one lives.
>
> Regarding the symmetric doubts. Such listeners will always be removed by
> passing in the undecorated object to removeListener.
> They should act like a transparent proxy.
>
> Even if this breaks the equals paradigm, in this special case I can
> perfectly live with an equals/hashCode implementation like this below.
> It won’t break your app; as long as both objects do not live in the same
> HashSet/Map …. for sure - but why should they?
>
> @Override
> public boolean equals(Object obj)
> {
> return obj == delegate; // && this == obj
> }
>
> @Override
> public int hashCode()
> {
> return delegate.hashCode();
> }
>
>
> Regards,
> Mario
>
>
> Am 22.03.2014 um 14:22 schrieb Tomas Mikula :
>
>
>
> A simpler and more universal solution is to also override removeListener:
>
> public void removeListener(ChangeListener listener) {
>super.removeListener(decorated(listener));
> }
>
> And the equals() method on decorated listeners only compares the
> delegates (thus is symmetric).
>
> Regards,
> Tomas
>
>
> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula 
> wrote:
>
>
> The suspicious thing about your solution is that your smart
> implementation of equals() is not symmetric.
>
> In case the observable value is visible only within your project, you
> could do this:
>
>interface Subscription {
>void unsubscribe();
>}
>
>class MyObservableValue implements ObservableValue {
>public Subscription subscribe(ChangeListener listener) {
>ChangeListener decorated = decorate(listener);
>   addListener(decorated);
>   return () -> removeListener(decorated);
>}
>}
>
> and use subscribe()/unsubscribe() instead of addListener()/removeListener():
>
>Subscription sub = observableValue.subscribe(listener);
>// ...
>sub.unsubscribe();
>
> Of course this is not possible if you need to pass the observable
> value to the outside world as ObservableValue.
>
> Regards,
> Tomas
>
> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits 
> wrote:
>
>
> Hi!
>
> In one of my ObservableValue implementations I do have the need to decorate
> ChangeListener added to it.
> Today this is somewhat complicated to implement, as I have to keep a map of
> the original listener to the decorated one to being able to handle the
> removal process of a listener. Because the outside World did not know that I
> decorated the listener and the instance passed in to removeListener ist the
> undecorated one.
>
> We can make things easier with a small change in
> ExpressionHelper.removeListener. When iterating through the listener list,
> the listener passed in as argument to removeListener is asked if it is equal
> to the one stored
>
>if (listener.equals(changeListeners[index])) {
>
> If we flip this to
>
>if (changeListeners[index].equals(listener)) {
>
> a listener decoration can be smart enough to not only check against itself,
> but also against its delegate.
>
> What do you think?
>
> I could prepare a patch for the *ExpressionHelper classes.
>
>
> Best regards,
> Mario
>
>
>
>
>
>
>

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

Yep, null throws a NullPointerException in addListener by design (also in 
removeListener) - the listener collection is safe.



Am 22.03.2014 um 15:50 schrieb Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>>:

What if changeListeners[index] is null? Maybe this is already illegal

Anyway, let's see what Martin has to say. In the mean time you file a JIRA 
enhancement request (issuetype=Tweak) if you like.

-- Kevin


Mario Ivankovits wrote:
The only thing which I ask for is to flip this „if" in the *ExpressionHelper 
classes:
So, JavaFX does not break anything and it is up to the app developer to take 
the risk or not.


   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener))



Am 22.03.2014 um 15:42 schrieb Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>>:

If you are talking about a change to the JavaFX API, we are not likely to 
accept such a change if it breaks the contract of equals() or hashcode(). In 
your own app it may not matter, but it is dangerous to assume it won't matter 
to anyone. Martin owns the core libraries and can comment further.

-- Kevin


Mario Ivankovits wrote:

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX 
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult 
a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by 
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can perfectly 
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same 
HashSet/Map …. for sure - but why should they?

@Override
public boolean equals(Object obj)
{
return obj == delegate; // && this == obj
}

@Override
public int hashCode()
{
return delegate.hashCode();
}


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula 
:



A simpler and more universal solution is to also override removeListener:

public void removeListener(ChangeListener listener) {
   super.removeListener(decorated(listener));
}

And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).

Regards,
Tomas


On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula 
 wrote:


The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.

In case the observable value is visible only within your project, you
could do this:

   interface Subscription {
   void unsubscribe();
   }

   class MyObservableValue implements ObservableValue {
   public Subscription subscribe(ChangeListener listener) {
   ChangeListener decorated = decorate(listener);
  addListener(decorated);
  return () -> removeListener(decorated);
   }
   }

and use subscribe()/unsubscribe() instead of addListener()/removeListener():

   Subscription sub = observableValue.subscribe(listener);
   // ...
   sub.unsubscribe();

Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.

Regards,
Tomas

On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits 
 wrote:


Hi!

In one of my ObservableValue implementations I do have the need to decorate 
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the 
original listener to the decorated one to being able to handle the removal 
process of a listener. Because the outside World did not know that I decorated 
the listener and the instance passed in to removeListener ist the undecorated 
one.

We can make things easier with a small change in 
ExpressionHelper.removeListener. When iterating through the listener list, the 
listener passed in as argument to removeListener is asked if it is equal to the 
one stored

   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener)) {

a listener decoration can be smart enough to not only check against itself, but 
also against its delegate.

What do you think?

I could prepare a patch for the *ExpressionHelper classes.


Best regards,
Mario

Re: Ability to decorate ChangeListener

[Kevin Rushforth]

What if changeListeners[index] is null? Maybe this is already illegal

Anyway, let's see what Martin has to say. In the mean time you file a 
JIRA enhancement request (issuetype=Tweak) if you like.


-- Kevin


Mario Ivankovits wrote:
The only thing which I ask for is to flip this „if" in the 
*ExpressionHelper classes:
So, JavaFX does not break anything and it is up to the app developer 
to take the risk or not.



   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener)) 




Am 22.03.2014 um 15:42 schrieb Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>>:


If you are talking about a change to the JavaFX API, we are not 
likely to accept such a change if it breaks the contract of equals() 
or hashcode(). In your own app it may not matter, but it is dangerous 
to assume it won't matter to anyone. Martin owns the core libraries 
and can comment further.


-- Kevin


Mario Ivankovits wrote:

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX 
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult 
a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by 
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can perfectly 
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same HashSet/Map …. for sure - but why should they? 


@Override
public boolean equals(Object obj)
{
return obj == delegate; // && this == obj
}

@Override
public int hashCode()
{
return delegate.hashCode();
}


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula :

  

A simpler and more universal solution is to also override removeListener:

public void removeListener(ChangeListener listener) {
   super.removeListener(decorated(listener));
}

And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).

Regards,
Tomas


On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula  wrote:


The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.

In case the observable value is visible only within your project, you
could do this:

   interface Subscription {
   void unsubscribe();
   }

   class MyObservableValue implements ObservableValue {
   public Subscription subscribe(ChangeListener listener) {
   ChangeListener decorated = decorate(listener);
  addListener(decorated);
  return () -> removeListener(decorated);
   }
   }

and use subscribe()/unsubscribe() instead of addListener()/removeListener():

   Subscription sub = observableValue.subscribe(listener);
   // ...
   sub.unsubscribe();

Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.

Regards,
Tomas

On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits  wrote:
  

Hi!

In one of my ObservableValue implementations I do have the need to decorate 
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the 
original listener to the decorated one to being able to handle the removal 
process of a listener. Because the outside World did not know that I decorated 
the listener and the instance passed in to removeListener ist the undecorated 
one.

We can make things easier with a small change in 
ExpressionHelper.removeListener. When iterating through the listener list, the 
listener passed in as argument to removeListener is asked if it is equal to the 
one stored

   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener)) {

a listener decoration can be smart enough to not only check against itself, but 
also against its delegate.

What do you think?

I could prepare a patch for the *ExpressionHelper classes.


Best regards,
Mario





  

Re: LNK1123: failure during conversion to COFF when building under windows

[Kevin Rushforth]

Do you have VS 2010 Service Pack 1? I've seen this failure on machines 
that don't have SP1 installed.


-- Kevin


Michael Berry wrote:

Hi,

I'm currently trying to build OpenJFX from source on Windows - I've
followed the instructions on the build page and have Visual Studio 2010,
the June 2010 directx sdk, cygwin and its relevant modules installed.
However, when building it fails at the buildJavaFXPackage task (output
below.)

I'm not sure if those warnings are normal or not, but they definitely look
suspicious. It seems the actual error that's stopping things is the "fatal
error LNK1123: failure during conversion to COFF: file invalid or corrupt"
line, though all I've found searching around for that error is that
"incremental:off" should be set to avoid it, which it already is in the
gradle task.

Any ideas?

Thanks,

Michael

:fxml:jar
:fxml:assemble
:fxpackager:buildJavaFXPackager
javafxpackager.cpp
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258)
: warning C4018: '<' : signed/unsigned mismatch
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269)
: warning C4018: '<' : signed/unsigned mismatch
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286)
: warning C4018: '<' : signed/unsigned mismatch
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426)
: warning C4996: 'getenv': This function or variable may be unsafe.
Consider using _dupenv_s instead. To disable deprecation,use
_CRT_SECURE_NO_WARNINGS. See online help for details.
C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal
error LNK1123: failure during conversion to COFF: file invalid or corrupt
:fxpackager:buildJavaFXPackager FAILED

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817

* What went wrong:
Execution failed for task ':fxpackager:buildJavaFXPackager'.
  

Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio


10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123
  

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

The only thing which I ask for is to flip this „if" in the *ExpressionHelper 
classes:
So, JavaFX does not break anything and it is up to the app developer to take 
the risk or not.


   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener))



Am 22.03.2014 um 15:42 schrieb Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>>:

If you are talking about a change to the JavaFX API, we are not likely to 
accept such a change if it breaks the contract of equals() or hashcode(). In 
your own app it may not matter, but it is dangerous to assume it won't matter 
to anyone. Martin owns the core libraries and can comment further.

-- Kevin


Mario Ivankovits wrote:

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX 
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult 
a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by 
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can perfectly 
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same 
HashSet/Map …. for sure - but why should they?

@Override
public boolean equals(Object obj)
{
return obj == delegate; // && this == obj
}

@Override
public int hashCode()
{
return delegate.hashCode();
}


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula 
:



A simpler and more universal solution is to also override removeListener:

public void removeListener(ChangeListener listener) {
   super.removeListener(decorated(listener));
}

And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).

Regards,
Tomas


On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula 
 wrote:


The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.

In case the observable value is visible only within your project, you
could do this:

   interface Subscription {
   void unsubscribe();
   }

   class MyObservableValue implements ObservableValue {
   public Subscription subscribe(ChangeListener listener) {
   ChangeListener decorated = decorate(listener);
  addListener(decorated);
  return () -> removeListener(decorated);
   }
   }

and use subscribe()/unsubscribe() instead of addListener()/removeListener():

   Subscription sub = observableValue.subscribe(listener);
   // ...
   sub.unsubscribe();

Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.

Regards,
Tomas

On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits 
 wrote:


Hi!

In one of my ObservableValue implementations I do have the need to decorate 
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the 
original listener to the decorated one to being able to handle the removal 
process of a listener. Because the outside World did not know that I decorated 
the listener and the instance passed in to removeListener ist the undecorated 
one.

We can make things easier with a small change in 
ExpressionHelper.removeListener. When iterating through the listener list, the 
listener passed in as argument to removeListener is asked if it is equal to the 
one stored

   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener)) {

a listener decoration can be smart enough to not only check against itself, but 
also against its delegate.

What do you think?

I could prepare a patch for the *ExpressionHelper classes.


Best regards,
Mario

Re: Ability to decorate ChangeListener

[Kevin Rushforth]

If you are talking about a change to the JavaFX API, we are not likely 
to accept such a change if it breaks the contract of equals() or 
hashcode(). In your own app it may not matter, but it is dangerous to 
assume it won't matter to anyone. Martin owns the core libraries and can 
comment further.


-- Kevin


Mario Ivankovits wrote:

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX 
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult 
a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by 
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can perfectly 
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same HashSet/Map …. for sure - but why should they? 


@Override
public boolean equals(Object obj)
{
return obj == delegate; // && this == obj
}

@Override
public int hashCode()
{
return delegate.hashCode();
}


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula :

  

A simpler and more universal solution is to also override removeListener:

public void removeListener(ChangeListener listener) {
   super.removeListener(decorated(listener));
}

And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).

Regards,
Tomas


On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula  wrote:


The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.

In case the observable value is visible only within your project, you
could do this:

   interface Subscription {
   void unsubscribe();
   }

   class MyObservableValue implements ObservableValue {
   public Subscription subscribe(ChangeListener listener) {
   ChangeListener decorated = decorate(listener);
  addListener(decorated);
  return () -> removeListener(decorated);
   }
   }

and use subscribe()/unsubscribe() instead of addListener()/removeListener():

   Subscription sub = observableValue.subscribe(listener);
   // ...
   sub.unsubscribe();

Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.

Regards,
Tomas

On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits  wrote:
  

Hi!

In one of my ObservableValue implementations I do have the need to decorate 
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the 
original listener to the decorated one to being able to handle the removal 
process of a listener. Because the outside World did not know that I decorated 
the listener and the instance passed in to removeListener ist the undecorated 
one.

We can make things easier with a small change in 
ExpressionHelper.removeListener. When iterating through the listener list, the 
listener passed in as argument to removeListener is asked if it is equal to the 
one stored

   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener)) {

a listener decoration can be smart enough to not only check against itself, but 
also against its delegate.

What do you think?

I could prepare a patch for the *ExpressionHelper classes.


Best regards,
Mario





  

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX 
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult 
a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by 
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can perfectly 
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same 
HashSet/Map …. for sure - but why should they? 

@Override
public boolean equals(Object obj)
{
return obj == delegate; // && this == obj
}

@Override
public int hashCode()
{
return delegate.hashCode();
}


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula :

> A simpler and more universal solution is to also override removeListener:
> 
> public void removeListener(ChangeListener listener) {
>super.removeListener(decorated(listener));
> }
> 
> And the equals() method on decorated listeners only compares the
> delegates (thus is symmetric).
> 
> Regards,
> Tomas
> 
> 
> On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula  wrote:
>> The suspicious thing about your solution is that your smart
>> implementation of equals() is not symmetric.
>> 
>> In case the observable value is visible only within your project, you
>> could do this:
>> 
>>interface Subscription {
>>void unsubscribe();
>>}
>> 
>>class MyObservableValue implements ObservableValue {
>>public Subscription subscribe(ChangeListener listener) {
>>ChangeListener decorated = decorate(listener);
>>   addListener(decorated);
>>   return () -> removeListener(decorated);
>>}
>>}
>> 
>> and use subscribe()/unsubscribe() instead of addListener()/removeListener():
>> 
>>Subscription sub = observableValue.subscribe(listener);
>>// ...
>>sub.unsubscribe();
>> 
>> Of course this is not possible if you need to pass the observable
>> value to the outside world as ObservableValue.
>> 
>> Regards,
>> Tomas
>> 
>> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits  wrote:
>>> Hi!
>>> 
>>> In one of my ObservableValue implementations I do have the need to decorate 
>>> ChangeListener added to it.
>>> Today this is somewhat complicated to implement, as I have to keep a map of 
>>> the original listener to the decorated one to being able to handle the 
>>> removal process of a listener. Because the outside World did not know that 
>>> I decorated the listener and the instance passed in to removeListener ist 
>>> the undecorated one.
>>> 
>>> We can make things easier with a small change in 
>>> ExpressionHelper.removeListener. When iterating through the listener list, 
>>> the listener passed in as argument to removeListener is asked if it is 
>>> equal to the one stored
>>> 
>>>if (listener.equals(changeListeners[index])) {
>>> 
>>> If we flip this to
>>> 
>>>if (changeListeners[index].equals(listener)) {
>>> 
>>> a listener decoration can be smart enough to not only check against itself, 
>>> but also against its delegate.
>>> 
>>> What do you think?
>>> 
>>> I could prepare a patch for the *ExpressionHelper classes.
>>> 
>>> 
>>> Best regards,
>>> Mario
>>> 
>>> 

Re: *PropertyBase vs Simple*Property

[Tomas Mikula]

On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
 wrote:
> Hi Richard,
>
> Coming back to this old thread and now that we are using lamdas all over
> I guess we could take one more look into that.
>
> I've prototyped an initial version by introducing a new internal type
> named InvalidatedSimpleObjectProperty (not the best name ever!) - see
> code pasted below.
>
> And now one can write code like this:
>
>> public final ObjectProperty viewportProperty() {
>> if (viewport == null) {
>> viewport = new InvalidatedSimpleObjectProperty<>(this, 
>> "viewport", (o) -> {
>>   invalidateWidthHeight();
>> impl_markDirty(DirtyBits.NODE_VIEWPORT);
>> impl_geomChanged();
>> } );
>> }
>> return viewport;
>> }
>
> instead of
>
>> public final ObjectProperty viewportProperty() {
>> if (viewport == null) {
>> viewport = new ObjectPropertyBase() {
>>
>> @Override
>> protected void invalidated() {
>> invalidateWidthHeight();
>> impl_markDirty(DirtyBits.NODE_VIEWPORT);
>> impl_geomChanged();
>> }
>>
>> @Override
>> public Object getBean() {
>> return ImageView.this;
>> }
>>
>> @Override
>> public String getName() {
>> return "viewport";
>> }
>> };
>> }
>> return viewport;
>> }

Nice idea. Just to get the comparison to status quo more fair, you
don't need to override getBean() and getName() methods:

public final ObjectProperty viewportProperty() {
if (viewport == null) {
viewport = new SimpleObjectProperty(this, "viewport") {

@Override
protected void invalidated() {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
}
};
}
return viewport;
}

Regards,
Tomas

>
> Which allows us to get rid of most of the ObjectPropertyBase sublcasses.
>
> Tom
>
>
>> package com.sun.javafx.property;
>>
>> import java.util.function.Consumer;
>>
>> import javafx.beans.property.SimpleObjectProperty;
>>
>> public final class InvalidatedSimpleObjectProperty extends 
>> SimpleObjectProperty {
>>   private final Consumer> 
>> invalidationConsumer;
>>
>> /**
>>  * The constructor of {@code ObjectProperty}
>>  *
>>  * @param initialValue
>>  *the initial value of the wrapped value
>>  * @param invalidationConsumer
>>  *  the consumer to be called when the bean is 
>> invalidated
>>  */
>> public InvalidatedSimpleObjectProperty(T initialValue, final 
>> Consumer> invalidationConsumer) {
>> super(initialValue);
>> if( invalidationConsumer == null ) {
>>   throw new IllegalArgumentException("Consumer can not be null");
>> }
>> this.invalidationConsumer = invalidationConsumer;
>> }
>>
>> /**
>>  * The constructor of {@code ObjectProperty}
>>  *
>>  * @param bean
>>  *the bean of this {@code ObjectProperty}
>>  * @param name
>>  *the name of this {@code ObjectProperty}
>>  * @param invalidationConsumer
>>  *  the consumer to be called when the bean is 
>> invalidated
>>  */
>> public InvalidatedSimpleObjectProperty(Object bean, String name, final 
>> Consumer> invalidationConsumer) {
>>super(bean, name);
>>if( invalidationConsumer == null ) {
>>   throw new IllegalArgumentException("Consumer can not be null");
>>}
>>this.invalidationConsumer = invalidationConsumer;
>> }
>>
>> /**
>>  * The constructor of {@code ObjectProperty}
>>  *
>>  * @param bean
>>  *the bean of this {@code ObjectProperty}
>>  * @param name
>>  *the name of this {@code ObjectProperty}
>>  * @param initialValue
>>  *the initial value of the wrapped value
>>  * @param invalidationConsumer
>>  *  the consumer to be called when the bean is 
>> invalidated
>>  */
>> public InvalidatedSimpleObjectProperty(Object bean, String name, T 
>> initialValue, final Consumer> 
>> invalidationConsumer) {
>> super(bean,name,initialValue);
>> if( invalidationConsumer == null ) {
>>   throw new IllegalArgumentException("Consumer can not be null");
>> }
>> this.invalidationConsumer = invalidationConsumer;
>> }
>>
>> @Override
>> protected void invalidated() {
>>   invalidationConsumer.accept(this);
>> }
>> }
>
>
> On 22.01.13 10:30, Richard Bair wrote:
>>> Is the Java8 plan still there if not should the current Simple*Property
>>> subclasses 

LNK1123: failure during conversion to COFF when building under windows

[Michael Berry]

Hi,

I'm currently trying to build OpenJFX from source on Windows - I've
followed the instructions on the build page and have Visual Studio 2010,
the June 2010 directx sdk, cygwin and its relevant modules installed.
However, when building it fails at the buildJavaFXPackage task (output
below.)

I'm not sure if those warnings are normal or not, but they definitely look
suspicious. It seems the actual error that's stopping things is the "fatal
error LNK1123: failure during conversion to COFF: file invalid or corrupt"
line, though all I've found searching around for that error is that
"incremental:off" should be set to avoid it, which it already is in the
gradle task.

Any ideas?

Thanks,

Michael

:fxml:jar
:fxml:assemble
:fxpackager:buildJavaFXPackager
javafxpackager.cpp
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258)
: warning C4018: '<' : signed/unsigned mismatch
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269)
: warning C4018: '<' : signed/unsigned mismatch
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286)
: warning C4018: '<' : signed/unsigned mismatch
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426)
: warning C4996: 'getenv': This function or variable may be unsafe.
Consider using _dupenv_s instead. To disable deprecation,use
_CRT_SECURE_NO_WARNINGS. See online help for details.
C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal
error LNK1123: failure during conversion to COFF: file invalid or corrupt
:fxpackager:buildJavaFXPackager FAILED

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817

* What went wrong:
Execution failed for task ':fxpackager:buildJavaFXPackager'.
> Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123

Re: Ability to decorate ChangeListener

[Tomas Mikula]

A simpler and more universal solution is to also override removeListener:

public void removeListener(ChangeListener listener) {
super.removeListener(decorated(listener));
}

And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).

Regards,
Tomas


On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula  wrote:
> The suspicious thing about your solution is that your smart
> implementation of equals() is not symmetric.
>
> In case the observable value is visible only within your project, you
> could do this:
>
> interface Subscription {
> void unsubscribe();
> }
>
> class MyObservableValue implements ObservableValue {
> public Subscription subscribe(ChangeListener listener) {
> ChangeListener decorated = decorate(listener);
>addListener(decorated);
>return () -> removeListener(decorated);
> }
> }
>
> and use subscribe()/unsubscribe() instead of addListener()/removeListener():
>
> Subscription sub = observableValue.subscribe(listener);
> // ...
> sub.unsubscribe();
>
> Of course this is not possible if you need to pass the observable
> value to the outside world as ObservableValue.
>
> Regards,
> Tomas
>
> On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits  wrote:
>> Hi!
>>
>> In one of my ObservableValue implementations I do have the need to decorate 
>> ChangeListener added to it.
>> Today this is somewhat complicated to implement, as I have to keep a map of 
>> the original listener to the decorated one to being able to handle the 
>> removal process of a listener. Because the outside World did not know that I 
>> decorated the listener and the instance passed in to removeListener ist the 
>> undecorated one.
>>
>> We can make things easier with a small change in 
>> ExpressionHelper.removeListener. When iterating through the listener list, 
>> the listener passed in as argument to removeListener is asked if it is equal 
>> to the one stored
>>
>> if (listener.equals(changeListeners[index])) {
>>
>> If we flip this to
>>
>> if (changeListeners[index].equals(listener)) {
>>
>> a listener decoration can be smart enough to not only check against itself, 
>> but also against its delegate.
>>
>> What do you think?
>>
>> I could prepare a patch for the *ExpressionHelper classes.
>>
>>
>> Best regards,
>> Mario
>>
>>

Error in tablevie ghost error

[siput]

Why when i clik in the area outside row contain a data and outside 
column area I get an error?


red area of eror

Re: Ability to decorate ChangeListener

[Tomas Mikula]

The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.

In case the observable value is visible only within your project, you
could do this:

interface Subscription {
void unsubscribe();
}

class MyObservableValue implements ObservableValue {
public Subscription subscribe(ChangeListener listener) {
ChangeListener decorated = decorate(listener);
   addListener(decorated);
   return () -> removeListener(decorated);
}
}

and use subscribe()/unsubscribe() instead of addListener()/removeListener():

Subscription sub = observableValue.subscribe(listener);
// ...
sub.unsubscribe();

Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.

Regards,
Tomas

On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits  wrote:
> Hi!
>
> In one of my ObservableValue implementations I do have the need to decorate 
> ChangeListener added to it.
> Today this is somewhat complicated to implement, as I have to keep a map of 
> the original listener to the decorated one to being able to handle the 
> removal process of a listener. Because the outside World did not know that I 
> decorated the listener and the instance passed in to removeListener ist the 
> undecorated one.
>
> We can make things easier with a small change in 
> ExpressionHelper.removeListener. When iterating through the listener list, 
> the listener passed in as argument to removeListener is asked if it is equal 
> to the one stored
>
> if (listener.equals(changeListeners[index])) {
>
> If we flip this to
>
> if (changeListeners[index].equals(listener)) {
>
> a listener decoration can be smart enough to not only check against itself, 
> but also against its delegate.
>
> What do you think?
>
> I could prepare a patch for the *ExpressionHelper classes.
>
>
> Best regards,
> Mario
>
>