Re: Ability to decorate ChangeListener
Mario,
thanks for your suggestion, but I think your specific case will not
justify the change. First of all, as it was already said, equals should
be symmetric. Knowing the implementation, you could rely on the fact
that either the equals is called on the provided listener or on the
listeners already in the list. Might be that somebody else would need
the asymmetry to be implemented in the listener provided to
removeListener() method and the current situation suits him, so why do
the change for your case?
Anyway, relying on some implementation-specific behaviour is generally a
sign of bad code practice, so it should give you a hint that you should
find a different solution (like the one you discussed with Tomas
already). It might happen that the code would be changed / re-factored
in the future or some bug would be fixed there and behaviour will change
again, breaking your application in some future JFX version.
Regards,
-Martin
On 22.3.2014 15:47, 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
kevin.rushfo...@oracle.commailto: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
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:
A simpler and more universal solution is to also override removeListener:
public void removeListener(ChangeListener? super T 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
tomas.mik...@gmail.commailto: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 MyObservableValueT implements ObservableValueT {
public Subscription subscribe(ChangeListener? extends T listener) {
ChangeListenerT 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
ma...@datenwort.atmailto: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
hg: openjfx/8u-dev/rt: RT-36139 [TableColumn] Inconsistent behaviour when resizing the last nested column on the right
Changeset: da21a84618ee Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-03-24 08:32 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/da21a84618ee RT-36139 [TableColumn] Inconsistent behaviour when resizing the last nested column on the right Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java
hg: openjfx/8u-dev/rt: RT-36255 Selecting TreeItem programatically expands collapsed Items
Changeset: 12c8e820eb46 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-03-24 08:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/12c8e820eb46 RT-36255 Selecting TreeItem programatically expands collapsed Items Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TreeView.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java
Re: Ability to decorate ChangeListener
Thanks for your answer!
One thing, I think, we can agree on, is that it is overly complex for an OO
language to decorate things like these listeners.
What about introducing another interface like ChangeListenerDecoration with a
special named „boolean decorates(ChangeListener)) method and call this if the
listeners hold by *ExpressionHelp class implements that interface?
BTW: If we care about symmetry, why not change the
listener.equals(otherListener) to listener == otherListener at all? Then, there
are not implementation details one can make use of.
I even might argue that it is a security risk to use the .equals() the way it
is now, as an evil listener implementation is able to remove all listeners from
the list by simply returning true from equals()
It should be the responsibility of the listener in the list to know if the
passed in listener justify the removal of itself, right? … from a security
standpoint! :-)
Regards,
Mario
Am 24.03.2014 um 07:31 schrieb Martin Sladecek martin.slade...@oracle.com:
Mario,
thanks for your suggestion, but I think your specific case will not justify
the change. First of all, as it was already said, equals should be symmetric.
Knowing the implementation, you could rely on the fact that either the equals
is called on the provided listener or on the listeners already in the list.
Might be that somebody else would need the asymmetry to be implemented in the
listener provided to removeListener() method and the current situation
suits him, so why do the change for your case?
Anyway, relying on some implementation-specific behaviour is generally a sign
of bad code practice, so it should give you a hint that you should find a
different solution (like the one you discussed with Tomas already). It might
happen that the code would be changed / re-factored in the future or some bug
would be fixed there and behaviour will change again, breaking your
application in some future JFX version.
Regards,
-Martin
On 22.3.2014 15:47, 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
kevin.rushfo...@oracle.commailto: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
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:
A simpler and more universal solution is to also override removeListener:
public void removeListener(ChangeListener? super T 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
tomas.mik...@gmail.commailto: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 MyObservableValueT implements ObservableValueT {
public Subscription subscribe(ChangeListener? extends T listener) {
ChangeListenerT decorated = decorate(listener);
addListener(decorated);
return () - removeListener(decorated);
}
}
and use subscribe()/unsubscribe() instead of
Re: Ability to decorate ChangeListener
On 24.3.2014 15:24, Mario Ivankovits wrote: But, after this discussion I do not see why one ever used .equals() at all. Look, it does not fit my needs, I do not see any use-case where one would add an removeListener with asymmetric .equals() and thus it is better you use == I think. This clarifies that EXACTLY the added listener instance is required to remove any listener AND it gives no room to discussions like we had because the indention is perfectly clear - even to those reading JavaFX core code and bug fixing things in JavaFX. For me this would be fine and understandable - I will go the decorator-cache-map so I will be fine always. One example might be in bidirectional binding. There's a special listener that takes the 2 properties that are bound together and it's equals returns true if the other listener is of the same class and it's two properties (no matter in what order) are identical. This way, you can just write Bindings.unbindBidirectional() and the internal implementation does not need to remember the listener instance anywhere. The equals() is symmetric in this case, but == would not work here. -Martin
Re: How to build 64-bit FX ?
Previously I simply did `rm -rf caches`, but this didn't seem to do the right job. After a completely fresh clone of a new repo and performing a build using 64-bit JDK, I finally got it working. -- best regards, Anthony On 3/21/2014 8:26 PM, Anthony Petrov wrote: Thanks, Kevin. The build went fine. However, when starting an app, I get the infamous NoSuchMethodError: notifyInitAccessibility exception (I'm building a fresh 8u20 repo). I tried to specify -Djava.library.path=artifacts\sdk\rt\bin but this didn't help. Note that the x64 JDK I'm using to run the app has its jfxrt.jar removed. But(!), I can actually run the app using the (supposed to be) 64-bit FX binaries with a 32-bit JDK. And it runs fine in this case. But how this could possibly work? And most importantly, how do I get it work with a 64-bit JDK? -- best regards, Anthony On 3/21/2014 6:46 PM, Kevin Rushforth wrote: If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX build. No additional options are needed. You need to do a gradle clean as part of your build if you previously built a 32-build in the same repo. Also, if not building webkit or media, make sure you update your stub_runtime to point to 64-bit FX binaries (your caches dir if doing a closed build). -- Kevin Anthony Petrov wrote: Hello, I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a 32-bit JDK, and when building FX by executing the `gradle` command, I get a 32-bit FX build. How do I get a 64-bit FX build on the same system? What additional software do I need? I suppose I need a 64-bit JDK, right? I have VS2010 Professional installed. Do I need to install any additional development tools/compilers? What options/environment variables do I specify on the command line to run gradle and get a 64-bit FX build? -- best regards, Anthony
Re: Adding GStreamer plugins
Hi Michael, On 24.03.2014 4:31, Michael Berry wrote: Hi all, I'm now a bit further along with this, though struggling to get the matroska plugin to compile (getting a bunch of unresolved external symbol errors for functions it uses in glib - not entirely sure why at the moment, as I said C is not my strong point.) I've also noticed the plugins currently bundled have quite a few changes to the gstreamer version, and I can't quite work out the logic behind why things have been changed the way they have - so even after the compilation issue is resolved I'm now less confident that it will just drop in and work! Again, if someone knowledgeable in this area that's lurking in the shadows could shed any light on any of this, it would be hugely appreciated. However, putting the current problems aside for a bit, the snags I hit up until this point could I think be relatively easily addressed in the documentation. With that in mind could I suggest a few additional points for the wiki? These may be obvious to the majority reading here, but as someone completely new to building JFX they had me stumped for a while! - It turns out that the Gstreamer stuff doesn't compile at all by default, which is why I wasn't seeing any changes on the native level. To ensure GStreamer is actually compiled, you need to copy the gradle.properties.template file to gradle.properties, and uncomment the #COMPILE_MEDIA = true line. (A similar scenario would appear to exist for any webkit alterations as per the line above.) You may just add -PCOMPILE_MEDIA=true as a gradle argument. You may also want to add -PCONF=DebugNative to build debug version (in case if you didn't find that option yet) Regards, Anton. - As well as the requirements listed, I needed the Windows SDK ( http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed for GStreamer to compile successfully under Windows (7) - without it cygpath just threw a rather confusing error. - The DirectX SDK failed to install for me, Googling found the fix relatively easily ( http://stackoverflow.com/questions/4102259/directx-sdk-june-2010-installation-problems-error-code-s1023), but perhaps this could be included just for reference. - The developer workflow page ( https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers to -Djavafx.ext.dirs - I think this should be -Djava.ext.dirs instead? I'm happy to make the above changes myself but unsure of if / where you can sign up for an account, so I'm just throwing them here for now - if anyone could point me to the right place then that'd be great! If I do ever manage to get this working (ha-ha) I'd also like to throw up a wiki page just detailing how to grab a gstreamer plugin and make the necessary changes to it to compile it into openjfx as a stop gap to then perhaps working on one or both of the above JIRA issues and seeing where I get - does this sound reasonable? Many thanks, Michael On 23 March 2014 15:32, Michael Berry berry...@gmail.com wrote: Hi Scott, Sure, that's in fact my eventual goal - but in order to successfully get that far I need to work out how to compile OpenJFX with other GStreamer plugins first, and unfortunately at the moment I seem to be getting stuck at that hurdle! Time permitting, I do indeed plan to look at addressing 2684 if I can get that far. Thanks, Michael On 23 March 2014 14:03, Scott Palmer swpal...@gmail.com wrote: I applaud your effort, but please consider while you are doing this: Addressing RT-18009 is good Addressing RT-2684 is way better. https://javafx-jira.kenai.com/browse/RT-2684 If there is a mechanism to write a stub plugin that hooks into the GStreamer plugin mechanism such that end users of JavaFX can write a module (in Java, with the option of using JNI) that supplies the uncompressed frames via a NativeByteBuffer, that would be a great start. Scott On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote: 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/
Re: Ability to decorate ChangeListener
Am 24.03.2014 um 15:36 schrieb Martin Sladecek martin.slade...@oracle.com: On 24.3.2014 15:24, Mario Ivankovits wrote: But, after this discussion I do not see why one ever used .equals() at all. Look, it does not fit my needs, I do not see any use-case where one would add an removeListener with asymmetric .equals() and thus it is better you use == I think. This clarifies that EXACTLY the added listener instance is required to remove any listener AND it gives no room to discussions like we had because the indention is perfectly clear - even to those reading JavaFX core code and bug fixing things in JavaFX. For me this would be fine and understandable - I will go the decorator-cache-map so I will be fine always. One example might be in bidirectional binding. There's a special listener that takes the 2 properties that are bound together and it's equals returns true if the other listener is of the same class and it's two properties (no matter in what order) are identical. This way, you can just write Bindings.unbindBidirectional() and the internal implementation does not need to remember the listener instance anywhere. The equals() is symmetric in this case, but == would not work here. -Martin Ah - Thanks for this lesson! :-) OMG … just looked up the code. The implementation of BidirectionalBinding uses weak references and it might happen that you ExpressionHelperBase.trim() them out of the listener list if either side of the bound property got garbage collected. This means, if I decorated them, they will stay in my map because there is add/removeListener asymmetry. (just to use the word symmetry again ;-) ) So, it is even more complicated to decorate that stuff. How much I’d love to see a DecoratedListener interface like you have for WeakListener … but yay … :-( Thanks for listening anyway! :-) Regards, Mario
Re: Ability to decorate ChangeListener
On Mon, Mar 24, 2014 at 3:24 PM, Mario Ivankovits ma...@datenwort.at wrote:
Hi Tomas!
No worries, I’ll go the way on my own there then.
But, after this discussion I do not see why one ever used .equals() at all.
Look, it does not fit my needs, I do not see any use-case where one would add
an removeListener with asymmetric .equals() and thus it is better you use ==
I think.
As Martin pointed out, sometimes == doesn't work for you and you need
(symmetric) equals(). Another example is my proposed solution #2 to
your problem.
Also, using equals instead of identity comparison is consistent with
how Collection.remove() determines equality.
This clarifies that EXACTLY the added listener instance is required to remove
any listener AND it gives no room to discussions like we had because the
indention is perfectly clear - even to those reading JavaFX core code and bug
fixing things in JavaFX.
For me this would be fine and understandable - I will go the
decorator-cache-map so I will be fine always.
BTW: There are always implementation details one has to assume. For example,
I have to assume that the internals will always use the add/removeListener
methods and not modifying the list (or whatever) directly.
There is something which we need to hold on - even if there is no
documentation for things like this.
Any yay, if you patch some JavaFX core stuff, you will get deeper insights
and do not need to assume anymore, you KNOW how it works. Sometimes it is not
easy to misuse things then to get your job done! ;-)
Also, if there is a risk in there current implementation it does not help
killing the discussion with the argument that there are other risks too.
I am pretty well aware about stuff like that.
PS: I would love to explain in detail why I decorate change listener, but
this is out of scope of this thread.
Regards,
Mario
Am 24.03.2014 um 14:04 schrieb Tomas Mikula tomas.mik...@gmail.com:
Hi Mario,
On Mon, Mar 24, 2014 at 8:46 AM, Mario Ivankovits ma...@datenwort.at wrote:
Thanks for your answer!
One thing, I think, we can agree on, is that it is overly complex for an OO
language to decorate things like these listeners.
I'm curious why you need to decorate the listeners in the first place.
What about introducing another interface like ChangeListenerDecoration with
a special named „boolean decorates(ChangeListener)) method and call this if
the listeners hold by *ExpressionHelp class implements that interface?
If you are writing your own ObservableValue implementation, you can as
well implement your own ExpressionHelper that does whatever you want
(just that you don't forget this option ;-)).
BTW: If we care about symmetry, why not change the
listener.equals(otherListener) to listener == otherListener at all? Then,
there are not implementation details one can make use of.
I even might argue that it is a security risk to use the .equals() the way
it is now, as an evil listener implementation is able to remove all
listeners from the list by simply returning true from equals()
It should be the responsibility of the listener in the list to know if the
passed in listener justify the removal of itself, right? … from a security
standpoint! :-)
You cannot secure your application at this level. An evil listener
might as well introduce memory leaks, cause stack overflow, or wipe
out your hard disk.
Tomas
Regards,
Mario
Am 24.03.2014 um 07:31 schrieb Martin Sladecek martin.slade...@oracle.com:
Mario,
thanks for your suggestion, but I think your specific case will not
justify the change. First of all, as it was already said, equals should be
symmetric. Knowing the implementation, you could rely on the fact that
either the equals is called on the provided listener or on the listeners
already in the list. Might be that somebody else would need the asymmetry
to be implemented in the listener provided to removeListener() method
and the current situation suits him, so why do the change for your case?
Anyway, relying on some implementation-specific behaviour is generally a
sign of bad code practice, so it should give you a hint that you should
find a different solution (like the one you discussed with Tomas already).
It might happen that the code would be changed / re-factored in the future
or some bug would be fixed there and behaviour will change again, breaking
your application in some future JFX version.
Regards,
-Martin
On 22.3.2014 15:47, 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
Re: How to build 64-bit FX ?
Good to hear that you can build OK now. -- Kevin Anthony Petrov wrote: Previously I simply did `rm -rf caches`, but this didn't seem to do the right job. After a completely fresh clone of a new repo and performing a build using 64-bit JDK, I finally got it working. -- best regards, Anthony On 3/21/2014 8:26 PM, Anthony Petrov wrote: Thanks, Kevin. The build went fine. However, when starting an app, I get the infamous NoSuchMethodError: notifyInitAccessibility exception (I'm building a fresh 8u20 repo). I tried to specify -Djava.library.path=artifacts\sdk\rt\bin but this didn't help. Note that the x64 JDK I'm using to run the app has its jfxrt.jar removed. But(!), I can actually run the app using the (supposed to be) 64-bit FX binaries with a 32-bit JDK. And it runs fine in this case. But how this could possibly work? And most importantly, how do I get it work with a 64-bit JDK? -- best regards, Anthony On 3/21/2014 6:46 PM, Kevin Rushforth wrote: If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX build. No additional options are needed. You need to do a gradle clean as part of your build if you previously built a 32-build in the same repo. Also, if not building webkit or media, make sure you update your stub_runtime to point to 64-bit FX binaries (your caches dir if doing a closed build). -- Kevin Anthony Petrov wrote: Hello, I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a 32-bit JDK, and when building FX by executing the `gradle` command, I get a 32-bit FX build. How do I get a 64-bit FX build on the same system? What additional software do I need? I suppose I need a 64-bit JDK, right? I have VS2010 Professional installed. Do I need to install any additional development tools/compilers? What options/environment variables do I specify on the command line to run gradle and get a 64-bit FX build? -- best regards, Anthony
Re: Ability to decorate ChangeListener
I'm pretty sure this discussion has solidified around not flipping the
equals() but this is a good example of something that we wouldn't
change. If you write code that relies on this, it will break in the
future when new code is added in FX that does not follow the pattern.
Steve
On 2014-03-22 10:47 AM, 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
kevin.rushfo...@oracle.commailto: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
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:
A simpler and more universal solution is to also override removeListener:
public void removeListener(ChangeListener? super T 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
tomas.mik...@gmail.commailto: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 MyObservableValueT implements ObservableValueT {
public Subscription subscribe(ChangeListener? extends T listener) {
ChangeListenerT 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
ma...@datenwort.atmailto: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 itself, but
also against its delegate.
What do you think?
I could prepare a patch for the *ExpressionHelper classes.
Best regards,
Mario
Re: Using JavaFX deploy and having signing issues...
Does anyone know how to codesign the jdk in the bundle created by JavaFX deploy ant task properly? I tried: codesign -f -s 3rd Party Mac Developer Application: Cert Name name.app/Contents/Plugins/jdk1.8.0.jdk I get the error: name.app/Contents/Plugins/jdk1.8.0.jdk bundle format unrecognized, invalid, or unsuitable I am wondering what was done with Ensemble to get past this issue. Thanks, -Tony On Sunday, March 23, 2014 4:52 PM, Tony Anecito adanec...@yahoo.com wrote: Hi, I am using JavaFX deploy ant task and having issue trying to sign because of jre embeded for Apple Store bundling. It is the last issue I have to fix then I can finish my Apple Store submission. Apparently even the jdk for the bundle has to be signed. To do that I had to redo permissions of jars and dylib files so the signing process would not error. My jars for my own app jars are code signed already. I am using the Apple find and codesign together so the jdk jre jars and dylib files get signed by codesign. Still I get error when submitting final pkg (with its own signing requirements) about invalid signature saying app not signed. I also discovered the JavaFX deploy lowercases my bundle id so it did not match bundle id registered with iconnect. I fixed the pinfo file so it matched. I would really like to see how this is all done with the ensemble app from the JavaFX group. Regards, -Tony
Re: Using JavaFX deploy and having signing issues...
I do this with my app, which works (though I don't submit it to the Mac App Store): codesign -s Developer ID Application RMStudio14.app jeff On Mar 24, 2014, at 11:26 AM, Tony Anecito adanec...@yahoo.com wrote: Does anyone know how to codesign the jdk in the bundle created by JavaFX deploy ant task properly? I tried: codesign -f -s 3rd Party Mac Developer Application: Cert Name name.app/Contents/Plugins/jdk1.8.0.jdk I get the error: name.app/Contents/Plugins/jdk1.8.0.jdk bundle format unrecognized, invalid, or unsuitable I am wondering what was done with Ensemble to get past this issue. Thanks, -Tony On Sunday, March 23, 2014 4:52 PM, Tony Anecito adanec...@yahoo.com wrote: Hi, I am using JavaFX deploy ant task and having issue trying to sign because of jre embeded for Apple Store bundling. It is the last issue I have to fix then I can finish my Apple Store submission. Apparently even the jdk for the bundle has to be signed. To do that I had to redo permissions of jars and dylib files so the signing process would not error. My jars for my own app jars are code signed already. I am using the Apple find and codesign together so the jdk jre jars and dylib files get signed by codesign. Still I get error when submitting final pkg (with its own signing requirements) about invalid signature saying app not signed. I also discovered the JavaFX deploy lowercases my bundle id so it did not match bundle id registered with iconnect. I fixed the pinfo file so it matched. I would really like to see how this is all done with the ensemble app from the JavaFX group. Regards, -Tony
Re: Using JavaFX deploy and having signing issues...
Mac app store signing is a bit more cranky. The line Jeff gives is fine for Gatekeeper. Here's what we do (in order) for the app store bundler coming in 8u20 - http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/eee373287ad8/modules/fxpackager/src/main/java/com/oracle/bundlers/mac/MacAppStoreBundler.java First, we sign all the dylibs and jars in the .app bundle. We search recursively. Second, we sign all contained executables in the .app. There are at least two for packager: the launcher we provide and a file jspawnhelper that the jdk uses for Runtime.exec. Third, we sign everything in Contents/PlugIns and Contents/Frameworks. Frameworks is usually empty but it's there for completeness. Finally we can actually sign the app itself. All of these signatures can be done with your 3rd party signing key (3rd Party Mac Developer Application: your name). Did I say finally? Silly me. We're not done. Now we package it all up with the `productbuild` tool, and pass in the installer key to the --sign argument (3rd Party Mac Developer Installer: your name). One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. With all of this I've been able to get past the static analysis guards Apple has set up for their app store submission. --Danno - Original Message - From: j...@reportmill.com To: adanec...@yahoo.com Cc: openjfx-dev@openjdk.java.net Sent: Monday, March 24, 2014 9:38:05 AM GMT -08:00 US/Canada Pacific Subject: Re: Using JavaFX deploy and having signing issues... I do this with my app, which works (though I don't submit it to the Mac App Store): codesign -s Developer ID Application RMStudio14.app jeff On Mar 24, 2014, at 11:26 AM, Tony Anecito adanec...@yahoo.com wrote: Does anyone know how to codesign the jdk in the bundle created by JavaFX deploy ant task properly? I tried: codesign -f -s 3rd Party Mac Developer Application: Cert Name name.app/Contents/Plugins/jdk1.8.0.jdk I get the error: name.app/Contents/Plugins/jdk1.8.0.jdk bundle format unrecognized, invalid, or unsuitable I am wondering what was done with Ensemble to get past this issue. Thanks, -Tony On Sunday, March 23, 2014 4:52 PM, Tony Anecito adanec...@yahoo.com wrote: Hi, I am using JavaFX deploy ant task and having issue trying to sign because of jre embeded for Apple Store bundling. It is the last issue I have to fix then I can finish my Apple Store submission. Apparently even the jdk for the bundle has to be signed. To do that I had to redo permissions of jars and dylib files so the signing process would not error. My jars for my own app jars are code signed already. I am using the Apple find and codesign together so the jdk jre jars and dylib files get signed by codesign. Still I get error when submitting final pkg (with its own signing requirements) about invalid signature saying app not signed. I also discovered the JavaFX deploy lowercases my bundle id so it did not match bundle id registered with iconnect. I fixed the pinfo file so it matched. I would really like to see how this is all done with the ensemble app from the JavaFX group. Regards, -Tony
Re: Using JavaFX deploy and having signing issues...
One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard
[8u] Review request: RT-36360 [Monocle] Slight refactor; cache native display in java instead of native code
Hi Daniel, Please review the following minor refactoring to the IMX monocle implementation: https://javafx-jira.kenai.com/browse/RT-36360 http://cr.openjdk.java.net/~kselle/webrev-20140324-1306-RT-36360/webrev/ Thanks, Lisa
Re: Using JavaFX deploy and having signing issues...
Thanks Richard, I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. I may have to downgrade my Mac OS X to 10.8 to create Apple Store distributable JavaFX apps for the Mac. -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair richard.b...@oracle.com wrote: One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard
Re: Using JavaFX deploy and having signing issues...
You can still deploy apps to the app store using JavaFX. You just cannot use the media library at the moment. You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in. And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito adanec...@yahoo.com wrote: Thanks Richard, I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. I may have to downgrade my Mac OS X to 10.8 to create Apple Store distributable JavaFX apps for the Mac. -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair richard.b...@oracle.com wrote: One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard
Re: Using JavaFX deploy and having signing issues...
So you have tried codesign with Mavericks OS X? I am getting invalid bundle when the jdk is bundled as required by the Apple Store. You have to codesign the jdk plugin seprately. Yes you can create a pkg or dmg image but I am looking for the correct way get the jdk codesigned else the app codesign fails also. Do you have a working example of codesign the jdk in the bundle? Thanks, -Tony On Monday, March 24, 2014 11:48 AM, Danno Ferrin danno.fer...@oracle.com wrote: You can still deploy apps to the app store using JavaFX. You just cannot use the media library at the moment. You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in. And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito adanec...@yahoo.com wrote: Thanks Richard, I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. I may have to downgrade my Mac OS X to 10.8 to create Apple Store distributable JavaFX apps for the Mac. -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair richard.b...@oracle.com wrote: One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard
Re: How to build 64-bit FX ?
Hi Kevin, I am doing a swing-javafx app and have been able to run on 64-bit OpenJDK and Windows Java. The only thing to watch out for is any native libraries. Those of course have to be 64-bit. Regards, -Tony On Monday, March 24, 2014 9:04 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Good to hear that you can build OK now. -- Kevin Anthony Petrov wrote: Previously I simply did `rm -rf caches`, but this didn't seem to do the right job. After a completely fresh clone of a new repo and performing a build using 64-bit JDK, I finally got it working. -- best regards, Anthony On 3/21/2014 8:26 PM, Anthony Petrov wrote: Thanks, Kevin. The build went fine. However, when starting an app, I get the infamous NoSuchMethodError: notifyInitAccessibility exception (I'm building a fresh 8u20 repo). I tried to specify -Djava.library.path=artifacts\sdk\rt\bin but this didn't help. Note that the x64 JDK I'm using to run the app has its jfxrt.jar removed. But(!), I can actually run the app using the (supposed to be) 64-bit FX binaries with a 32-bit JDK. And it runs fine in this case. But how this could possibly work? And most importantly, how do I get it work with a 64-bit JDK? -- best regards, Anthony On 3/21/2014 6:46 PM, Kevin Rushforth wrote: If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX build. No additional options are needed. You need to do a gradle clean as part of your build if you previously built a 32-build in the same repo. Also, if not building webkit or media, make sure you update your stub_runtime to point to 64-bit FX binaries (your caches dir if doing a closed build). -- Kevin Anthony Petrov wrote: Hello, I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a 32-bit JDK, and when building FX by executing the `gradle` command, I get a 32-bit FX build. How do I get a 64-bit FX build on the same system? What additional software do I need? I suppose I need a 64-bit JDK, right? I have VS2010 Professional installed. Do I need to install any additional development tools/compilers? What options/environment variables do I specify on the command line to run gradle and get a 64-bit FX build? -- best regards, Anthony
Re: How to build 64-bit FX ?
Good to know. Thanks. -- Kevin Tony Anecito wrote: Hi Kevin, I am doing a swing-javafx app and have been able to run on 64-bit OpenJDK and Windows Java. The only thing to watch out for is any native libraries. Those of course have to be 64-bit. Regards, -Tony On Monday, March 24, 2014 9:04 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Good to hear that you can build OK now. -- Kevin Anthony Petrov wrote: Previously I simply did `rm -rf caches`, but this didn't seem to do the right job. After a completely fresh clone of a new repo and performing a build using 64-bit JDK, I finally got it working. -- best regards, Anthony On 3/21/2014 8:26 PM, Anthony Petrov wrote: Thanks, Kevin. The build went fine. However, when starting an app, I get the infamous NoSuchMethodError: notifyInitAccessibility exception (I'm building a fresh 8u20 repo). I tried to specify -Djava.library.path=artifacts\sdk\rt\bin but this didn't help. Note that the x64 JDK I'm using to run the app has its jfxrt.jar removed. But(!), I can actually run the app using the (supposed to be) 64-bit FX binaries with a 32-bit JDK. And it runs fine in this case. But how this could possibly work? And most importantly, how do I get it work with a 64-bit JDK? -- best regards, Anthony On 3/21/2014 6:46 PM, Kevin Rushforth wrote: If your JDK_HOME points to a 64-bit JDK then you will get a 64-bit FX build. No additional options are needed. You need to do a gradle clean as part of your build if you previously built a 32-build in the same repo. Also, if not building webkit or media, make sure you update your stub_runtime to point to 64-bit FX binaries (your caches dir if doing a closed build). -- Kevin Anthony Petrov wrote: Hello, I'm on Win7 64 bit system. Regularly I use 32-bit compilers and a 32-bit JDK, and when building FX by executing the `gradle` command, I get a 32-bit FX build. How do I get a 64-bit FX build on the same system? What additional software do I need? I suppose I need a 64-bit JDK, right? I have VS2010 Professional installed. Do I need to install any additional development tools/compilers? What options/environment variables do I specify on the command line to run gradle and get a 64-bit FX build? -- best regards, Anthony
hg: openjfx/8u-dev/rt: 5 new changesets
Changeset: 16300af5f9f5 Author:jgiles Date: 2014-03-18 14:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/16300af5f9f5 RT0-35880: HelloSanity: Menu does not handle accelerator keys correctly Bug was in HelloSanity, not the mnemonic / accelerator code. ! apps/toys/Hello/src/main/java/hello/TestBuilder.java Changeset: 20efa4fd3487 Author:jgiles Date: 2014-03-20 16:40 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/20efa4fd3487 RT-22842: [Accessibility] ColorPicker keyboard accessibility ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPalette.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/InputFieldSkin.java Changeset: 372a4994afcd Author:jgiles Date: 2014-03-20 16:46 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/372a4994afcd Fix pagination a11y issue spotted by dgrieve. ! modules/controls/src/main/java/javafx/scene/control/Pagination.java Changeset: 3ae761425325 Author:jgiles Date: 2014-03-25 10:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3ae761425325 RT-36266: [Accessibility] Implement scrolling ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/javafx/scene/control/ListView.java ! modules/controls/src/main/java/javafx/scene/control/ScrollBar.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeView.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Action.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Role.java ! modules/graphics/src/main/native-glass/win/GlassAccessible.cpp ! modules/graphics/src/main/native-glass/win/GlassAccessible.h Changeset: 35858482e928 Author:jgiles Date: 2014-03-25 10:04 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/35858482e928 RT0-35880: HelloSanity: Menu does not handle accelerator keys correctly Bug was in HelloSanity, not the mnemonic / accelerator code.
Re: *PropertyBase vs Simple*Property
Hi,
I've written a small sample to see what it gets me to check:
* creation overhead
* memory overhead
* call overhead
I'm not very good at this kind of thing so someone who knows to write
benchmarks might know a lot better - need to check out JMH most likely.
Anyways here are the numbers:
Topic Lambda Subclass
--
Create10M 372ms (0.3723) 220ms (0.2205)
Mem 108byte / instance 84byte / instance
Call-1M*10 42ms (0.042)35ms (0.035)
Call-1*1M 11ms (0.011)10ms (0.010)
So Lamda is considerable slower 40% and takes 20% more space, call
behavior is fairly the same. I'll try to learn about JMH.
Tom
package hello;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Consumer;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.ObjectPropertyBase;
import javafx.beans.property.SimpleObjectProperty;
public class TestMemory {
private static int oneIteration = 1_000_000;
private static int iterationCount = 10;
private static int invokationOverheadCallCount = 1_000_000;
private static boolean testLambda = false;
private static void testLambda(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleLambdaBean());
}
}
private static void testSubclass(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleSubclassBean());
}
}
public static void main(String[] args) {
System.err.println(Test Creation time);
System.err.println(==);
{
long timeDiffTotal = 0;
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
long s = System.currentTimeMillis();
if( testLambda ) {
testLambda(oneIteration, new
ArrayList());
} else {
testSubclass(oneIteration, new
ArrayList());
}
long e = System.currentTimeMillis();
long diff = e - s;
timeDiffTotal+=diff;
System.err.println(Creation time: + diff
+ (+diff * 1.0 / oneIteration+));
System.err.println(
-);
}
System.err.println(Average time: + timeDiffTotal
* 1.0 / (iterationCount * oneIteration));
}
ListTestObject target = new
ArrayListTestObject(iterationCount * oneIteration);
{
System.err.println();
System.err.println(Test Creation memory);
System.err.println(==);
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
if( testLambda ) {
testLambda(oneIteration, target);
} else {
testSubclass(oneIteration, target);
}
long freeDiff =
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
System.err.println(Memory: + freeDiff +
(+freeDiff * 1.0 / target.size()+));
System.err.println(
-);
}
System.err.println(Total objects created: +
target.size());
}
{
System.err.println();
System.err.println(Test invokation overhead (all then
times));
Re: Using JavaFX deploy and having signing issues...
Ok I was able to codesign and submit. The JavaFX deploy task is not creating a info.plist when the jdk is added to the bundle for the jdk. After submission there were some issues related to signing and it now requires a entitlements file for some things in the jre. Regards, -Tony On Monday, March 24, 2014 12:01 PM, Tony Anecito adanec...@yahoo.com wrote: So you have tried codesign with Mavericks OS X? I am getting invalid bundle when the jdk is bundled as required by the Apple Store. You have to codesign the jdk plugin seprately. Yes you can create a pkg or dmg image but I am looking for the correct way get the jdk codesigned else the app codesign fails also. Do you have a working example of codesign the jdk in the bundle? Thanks, -Tony On Monday, March 24, 2014 11:48 AM, Danno Ferrin danno.fer...@oracle.com wrote: You can still deploy apps to the app store using JavaFX. You just cannot use the media library at the moment. You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in. And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito adanec...@yahoo.com wrote: Thanks Richard, I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. I may have to downgrade my Mac OS X to 10.8 to create Apple Store distributable JavaFX apps for the Mac. -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair richard.b...@oracle.com wrote: One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard
Re: *PropertyBase vs Simple*Property
Those results are surprising. Is this an apples-to-apples comparison
with the only difference being a Lambda versus an equivalent anonymous
inner class?
-- Kevin
Tom Schindl wrote:
Hi,
I've written a small sample to see what it gets me to check:
* creation overhead
* memory overhead
* call overhead
I'm not very good at this kind of thing so someone who knows to write
benchmarks might know a lot better - need to check out JMH most likely.
Anyways here are the numbers:
Topic Lambda Subclass
--
Create10M 372ms (0.3723) 220ms (0.2205)
Mem 108byte / instance 84byte / instance
Call-1M*10 42ms (0.042)35ms (0.035)
Call-1*1M 11ms (0.011)10ms (0.010)
So Lamda is considerable slower 40% and takes 20% more space, call
behavior is fairly the same. I'll try to learn about JMH.
Tom
package hello;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Consumer;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.ObjectPropertyBase;
import javafx.beans.property.SimpleObjectProperty;
public class TestMemory {
private static int oneIteration = 1_000_000;
private static int iterationCount = 10;
private static int invokationOverheadCallCount = 1_000_000;
private static boolean testLambda = false;
private static void testLambda(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleLambdaBean());
}
}
private static void testSubclass(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleSubclassBean());
}
}
public static void main(String[] args) {
System.err.println(Test Creation time);
System.err.println(==);
{
long timeDiffTotal = 0;
for( int i = 0; i iterationCount; i++ ) {
System.err.println( Working for objects: + (i *
oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
long s = System.currentTimeMillis();
if( testLambda ) {
testLambda(oneIteration, new
ArrayList());
} else {
testSubclass(oneIteration, new
ArrayList());
}
long e = System.currentTimeMillis();
long diff = e - s;
timeDiffTotal+=diff;
System.err.println( Creation time: + diff +
(+diff * 1.0 / oneIteration+));
System.err.println(
-);
}
System.err.println( Average time: +
timeDiffTotal * 1.0 / (iterationCount * oneIteration));
}
ListTestObject target = new
ArrayListTestObject(iterationCount * oneIteration);
{
System.err.println();
System.err.println(Test Creation memory);
System.err.println(==);
for( int i = 0; i iterationCount; i++ ) {
System.err.println( Working for objects: + (i *
oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
if( testLambda ) {
testLambda(oneIteration, target);
} else {
testSubclass(oneIteration, target);
}
long freeDiff =
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
System.err.println( Memory: + freeDiff +
(+freeDiff * 1.0 / target.size()+));
System.err.println(
-);
}
System.err.println( Total objects created: +
target.size());
Re: *PropertyBase vs Simple*Property
The code I run is attached in the mail copy it to your env and run it
and flip the testLambda from true to false.
I might have been something dumb wrong but this is what I came up with.
Tom
On 24.03.14 23:31, Kevin Rushforth wrote:
Those results are surprising. Is this an apples-to-apples comparison
with the only difference being a Lambda versus an equivalent anonymous
inner class?
-- Kevin
Tom Schindl wrote:
Hi,
I've written a small sample to see what it gets me to check:
* creation overhead
* memory overhead
* call overhead
I'm not very good at this kind of thing so someone who knows to write
benchmarks might know a lot better - need to check out JMH most likely.
Anyways here are the numbers:
TopicLambda Subclass
--
Create10M372ms (0.3723) 220ms (0.2205)
Mem 108byte / instance 84byte / instance
Call-1M*10 42ms (0.042)35ms (0.035)
Call-1*1M11ms (0.011)10ms (0.010)
So Lamda is considerable slower 40% and takes 20% more space, call
behavior is fairly the same. I'll try to learn about JMH.
Tom
package hello;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Consumer;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.ObjectPropertyBase;
import javafx.beans.property.SimpleObjectProperty;
public class TestMemory {
private static int oneIteration = 1_000_000;
private static int iterationCount = 10;
private static int invokationOverheadCallCount = 1_000_000;
private static boolean testLambda = false;
private static void testLambda(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleLambdaBean());
}
}
private static void testSubclass(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleSubclassBean());
}
}
public static void main(String[] args) {
System.err.println(Test Creation time);
System.err.println(==);
{
long timeDiffTotal = 0;
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
long s = System.currentTimeMillis();
if( testLambda ) {
testLambda(oneIteration, new
ArrayList());
} else {
testSubclass(oneIteration, new
ArrayList());
}
long e = System.currentTimeMillis();
long diff = e - s;
timeDiffTotal+=diff;
System.err.println(Creation time: + diff
+ (+diff * 1.0 / oneIteration+));
System.err.println(
-);
}
System.err.println(Average time: + timeDiffTotal
* 1.0 / (iterationCount * oneIteration));
}
ListTestObject target = new
ArrayListTestObject(iterationCount * oneIteration);
{
System.err.println();
System.err.println(Test Creation memory);
System.err.println(==);
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
if( testLambda ) {
testLambda(oneIteration, target);
} else {
testSubclass(oneIteration, target);
}
long freeDiff =
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
System.err.println(Memory: + freeDiff +
(+freeDiff * 1.0 / target.size()+));
System.err.println(
-);
}
System.err.println(Total
Re: Using JavaFX deploy and having signing issues...
Tony and/or Danno, Would you mind documenting the steps that you had to go through to make a Mac application that was submittable to the Apple Store? I'm sure everyone who's struggling to create applications would appreciate the information. Cheers, Mark On Mon, Mar 24, 2014 at 3:30 PM, Tony Anecito adanec...@yahoo.com wrote: Ok I was able to codesign and submit. The JavaFX deploy task is not creating a info.plist when the jdk is added to the bundle for the jdk. After submission there were some issues related to signing and it now requires a entitlements file for some things in the jre. Regards, -Tony On Monday, March 24, 2014 12:01 PM, Tony Anecito adanec...@yahoo.com wrote: So you have tried codesign with Mavericks OS X? I am getting invalid bundle when the jdk is bundled as required by the Apple Store. You have to codesign the jdk plugin seprately. Yes you can create a pkg or dmg image but I am looking for the correct way get the jdk codesigned else the app codesign fails also. Do you have a working example of codesign the jdk in the bundle? Thanks, -Tony On Monday, March 24, 2014 11:48 AM, Danno Ferrin danno.fer...@oracle.com wrote: You can still deploy apps to the app store using JavaFX. You just cannot use the media library at the moment. You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in. And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito adanec...@yahoo.com wrote: Thanks Richard, I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. I may have to downgrade my Mac OS X to 10.8 to create Apple Store distributable JavaFX apps for the Mac. -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair richard.b...@oracle.com wrote: One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard
Re: Using JavaFX deploy and having signing issues...
Yes and we'll put them on the OpenJFX wiki. Steve On 2014-03-24 6:39 PM, Mark Fortner wrote: Tony and/or Danno, Would you mind documenting the steps that you had to go through to make a Mac application that was submittable to the Apple Store? I'm sure everyone who's struggling to create applications would appreciate the information. Cheers, Mark On Mon, Mar 24, 2014 at 3:30 PM, Tony Anecito adanec...@yahoo.com wrote: Ok I was able to codesign and submit. The JavaFX deploy task is not creating a info.plist when the jdk is added to the bundle for the jdk. After submission there were some issues related to signing and it now requires a entitlements file for some things in the jre. Regards, -Tony On Monday, March 24, 2014 12:01 PM, Tony Anecito adanec...@yahoo.com wrote: So you have tried codesign with Mavericks OS X? I am getting invalid bundle when the jdk is bundled as required by the Apple Store. You have to codesign the jdk plugin seprately. Yes you can create a pkg or dmg image but I am looking for the correct way get the jdk codesigned else the app codesign fails also. Do you have a working example of codesign the jdk in the bundle? Thanks, -Tony On Monday, March 24, 2014 11:48 AM, Danno Ferrin danno.fer...@oracle.com wrote: You can still deploy apps to the app store using JavaFX. You just cannot use the media library at the moment. You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in. And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito adanec...@yahoo.com wrote: Thanks Richard, I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. I may have to downgrade my Mac OS X to 10.8 to create Apple Store distributable JavaFX apps for the Mac. -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair richard.b...@oracle.com wrote: One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard
Re: *PropertyBase vs Simple*Property
Ups there was an error in my test for the last Call line so the numbers
there are:
38 (lambda) vs 32 (subclass)
package hello;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Consumer;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.ObjectPropertyBase;
import javafx.beans.property.SimpleObjectProperty;
public class TestMemory {
private static int oneIteration = 1_000_000;
private static int iterationCount = 10;
private static int invokationOverheadCallCount = 1_000_000;
private static boolean testLambda = false;
private static void testLambda(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleLambdaBean());
}
}
private static void testSubclass(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleSubclassBean());
}
}
public static void main(String[] args) {
System.err.println(Test Creation time);
System.err.println(==);
{
long timeDiffTotal = 0;
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
long s = System.currentTimeMillis();
if( testLambda ) {
testLambda(oneIteration, new
ArrayList());
} else {
testSubclass(oneIteration, new
ArrayList());
}
long e = System.currentTimeMillis();
long diff = e - s;
timeDiffTotal+=diff;
System.err.println(Creation time: + diff
+ (+diff * 1.0 / oneIteration+));
System.err.println(
-);
}
System.err.println(Average time: + timeDiffTotal
* 1.0 / (iterationCount * oneIteration));
}
ListTestObject target = new
ArrayListTestObject(iterationCount * oneIteration);
{
System.err.println();
System.err.println(Test Creation memory);
System.err.println(==);
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
if( testLambda ) {
testLambda(oneIteration, target);
} else {
testSubclass(oneIteration, target);
}
long freeDiff =
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
System.err.println(Memory: + freeDiff +
(+freeDiff * 1.0 / target.size()+));
System.err.println(
-);
}
System.err.println(Total objects created: +
target.size());
}
{
System.err.println();
System.err.println(Test invokation overhead (all then
times));
System.err.println(=);
long s = System.currentTimeMillis();
for( int i = 0; i oneIteration; i++ ) {
target.get(i).invalidate();
}
long e = System.currentTimeMillis();
long diff = e - s;
System.err.println(Total time calls: + diff);
System.err.println(Time per call: + diff * 1.0 /
invokationOverheadCallCount);
}
{
System.err.println();
Re: *PropertyBase vs Simple*Property
Arghhh time for bed:
Number is 179 vs 150 but I only ran it once so the numbers might be
completely bogus!
Tom
On 24.03.14 23:40, Tom Schindl wrote:
Ups there was an error in my test for the last Call line so the numbers
there are:
38 (lambda) vs 32 (subclass)
package hello;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Consumer;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.ObjectPropertyBase;
import javafx.beans.property.SimpleObjectProperty;
public class TestMemory {
private static int oneIteration = 1_000_000;
private static int iterationCount = 10;
private static int invokationOverheadCallCount = 1_000_000;
private static boolean testLambda = false;
private static void testLambda(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleLambdaBean());
}
}
private static void testSubclass(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleSubclassBean());
}
}
public static void main(String[] args) {
System.err.println(Test Creation time);
System.err.println(==);
{
long timeDiffTotal = 0;
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
long s = System.currentTimeMillis();
if( testLambda ) {
testLambda(oneIteration, new
ArrayList());
} else {
testSubclass(oneIteration, new
ArrayList());
}
long e = System.currentTimeMillis();
long diff = e - s;
timeDiffTotal+=diff;
System.err.println(Creation time: + diff
+ (+diff * 1.0 / oneIteration+));
System.err.println(
-);
}
System.err.println(Average time: + timeDiffTotal
* 1.0 / (iterationCount * oneIteration));
}
ListTestObject target = new
ArrayListTestObject(iterationCount * oneIteration);
{
System.err.println();
System.err.println(Test Creation memory);
System.err.println(==);
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
if( testLambda ) {
testLambda(oneIteration, target);
} else {
testSubclass(oneIteration, target);
}
long freeDiff =
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
System.err.println(Memory: + freeDiff +
(+freeDiff * 1.0 / target.size()+));
System.err.println(
-);
}
System.err.println(Total objects created: +
target.size());
}
{
System.err.println();
System.err.println(Test invokation overhead (all then
times));
System.err.println(=);
long s = System.currentTimeMillis();
for( int i = 0; i oneIteration; i++ ) {
target.get(i).invalidate();
}
long e = System.currentTimeMillis();
long diff = e - s;
System.err.println(Total time calls: + diff);
System.err.println(Time per call: + diff * 1.0 /
invokationOverheadCallCount);
}
{
hg: openjfx/8u-dev/rt: RT-32460: TextArea: Wrong behavior of CTRL-DOWN on Windows
Changeset: e08cbee88d7d Author:leifs Date: 2014-03-24 18:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e08cbee88d7d RT-32460: TextArea: Wrong behavior of CTRL-DOWN on Windows ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextAreaSkin.java
Re: Using JavaFX deploy and having signing issues...
I have already started doing that since the info I found on the web does not mention some of the issues I am running into. -Tony On Monday, March 24, 2014 4:40 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: Yes and we'll put them on the OpenJFX wiki. Steve On 2014-03-24 6:39 PM, Mark Fortner wrote: Tony and/or Danno, Would you mind documenting the steps that you had to go through to make a Mac application that was submittable to the Apple Store? I'm sure everyone who's struggling to create applications would appreciate the information. Cheers, Mark On Mon, Mar 24, 2014 at 3:30 PM, Tony Anecito adanec...@yahoo.com wrote: Ok I was able to codesign and submit. The JavaFX deploy task is not creating a info.plist when the jdk is added to the bundle for the jdk. After submission there were some issues related to signing and it now requires a entitlements file for some things in the jre. Regards, -Tony On Monday, March 24, 2014 12:01 PM, Tony Anecito adanec...@yahoo.com wrote: So you have tried codesign with Mavericks OS X? I am getting invalid bundle when the jdk is bundled as required by the Apple Store. You have to codesign the jdk plugin seprately. Yes you can create a pkg or dmg image but I am looking for the correct way get the jdk codesigned else the app codesign fails also. Do you have a working example of codesign the jdk in the bundle? Thanks, -Tony On Monday, March 24, 2014 11:48 AM, Danno Ferrin danno.fer...@oracle.com wrote: You can still deploy apps to the app store using JavaFX. You just cannot use the media library at the moment. You can do it also via non app store distribution and sign it via gatekeeper as well and keep the media libraries in. And it shouldn't matter what version of Mac OSX you use to build it. Tony Anecito adanec...@yahoo.com wrote: Thanks Richard, I know some more now. It seems with Mavericks 10.9 codesign and the bundle format that JavaFX deploy creates is no longer valid. There are starting to appear to be more references to this issue on the internet. So JavaFX apps can no longer be created and work on the Mac at least as far as the Apple Store is concerned. I may have to downgrade my Mac OS X to 10.8 to create Apple Store distributable JavaFX apps for the Mac. -Tony On Monday, March 24, 2014 10:57 AM, Richard Bair richard.b...@oracle.com wrote: One last hurdle, you need to remove the media library for JavaFX (lib/libjfxmedia.dylib) from your bundled JDK. It uses QuickTime and that is being disowned by apple. This may be fixed in a later 8u update, but not in 8.0.0_b132. Oh good grief, Apple! So what should we be using instead? This means I cannot make use of fx media in any app submitted to the app store? Richard
hg: openjfx/8u-dev/rt: 4 new changesets
Changeset: d21a135c84d5 Author:jgiles Date: 2014-03-25 10:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d21a135c84d5 RT-36334: Clean up warnings in control component Contributed-by: Tom Schindl tom.schi...@bestsolution.at Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/ScrollPane.java ! modules/controls/src/main/java/javafx/scene/control/Separator.java ! modules/controls/src/main/java/javafx/scene/control/Slider.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeView.java Changeset: f1e1491949bb Author:jgiles Date: 2014-03-25 11:25 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f1e1491949bb [Accessibility] Standardise controls files wrt accessibility code layout and positioning. ! modules/controls/src/main/java/javafx/scene/control/Accordion.java ! modules/controls/src/main/java/javafx/scene/control/Button.java ! modules/controls/src/main/java/javafx/scene/control/ButtonBase.java ! modules/controls/src/main/java/javafx/scene/control/CheckBox.java ! modules/controls/src/main/java/javafx/scene/control/ComboBoxBase.java ! modules/controls/src/main/java/javafx/scene/control/Control.java ! modules/controls/src/main/java/javafx/scene/control/Hyperlink.java ! modules/controls/src/main/java/javafx/scene/control/Label.java ! modules/controls/src/main/java/javafx/scene/control/Labeled.java ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/Pagination.java ! modules/controls/src/main/java/javafx/scene/control/PasswordField.java ! modules/controls/src/main/java/javafx/scene/control/ProgressBar.java ! modules/controls/src/main/java/javafx/scene/control/ProgressIndicator.java ! modules/controls/src/main/java/javafx/scene/control/RadioButton.java ! modules/controls/src/main/java/javafx/scene/control/ScrollPane.java ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java ! modules/controls/src/main/java/javafx/scene/control/Slider.java ! modules/controls/src/main/java/javafx/scene/control/TabPane.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/main/java/javafx/scene/control/TextArea.java ! modules/controls/src/main/java/javafx/scene/control/TextField.java ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/main/java/javafx/scene/control/TitledPane.java ! modules/controls/src/main/java/javafx/scene/control/ToggleButton.java ! modules/controls/src/main/java/javafx/scene/control/ToolBar.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java Changeset: fd6893fc1047 Author:jgiles Date: 2014-03-25 11:28 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/fd6893fc1047 [IntelliJ only] Don't include inspection profiles in rt repo. ! .hgignore Changeset: c61f0f745e0d Author:jgiles Date: 2014-03-25 15:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c61f0f745e0d RT-36280: ComboBox's popup cannot be closed with ENTER ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java ! modules/controls/src/test/java/javafx/scene/control/ComboBoxTest.java
