Re: Proposal on getting warning free (controls) packages
On 20/03/2014 20:57, Tom Schindl wrote:
Hi,
I've just started looking into getting the controls package warning free
and/or suppress them in case not fixable.
Most of the generic warnings I've come accross in a first pass involve
StyleableProperty cast like this:
((StyleableProperty)graphicProperty()).applyStyle(origin, null);
In fact above code has 2 warnings:
a) unchecked type cast
b) usage of raw-type
the raw type in this case can be fixed with:
((StyleablePropertyNode)graphicProperty()).applyStyle(origin, null);
leaving us with the unchecked cast so we could add:
@SuppressWarnings({ unchecked })
e.g. on the method but I'm uncertain this is a good idea because it
might hide unchecked warnings we have a possibility to fix.
If you are willing to expend another line of code, you could first
assign graphicProperty to a variable:
StylablePropertyNode property = (StyleablePropertyNode)graphicProperty();
property.applyStyle(origin, null);
You can then apply the unchecked annotation to the assignment only, so
future unchecked warnings in the same method will still be noticed.
--John
So what are other options:
a) Create a static helper in Util to make the cast and for us (we could
even add it as a static method in the StyleableProperty-interface)
b) provide a private/package-scoped method the public one delegates
Both of them work but have different problems where I think b) has the
bigger ones like blowing up class-file, modification of the field to be
of type StyleableObjectProperty.
I'd really like to get the source warning free.
Thoughts?
Tom
hg: openjfx/8u-dev/rt: RT-36235: Zero specular power can lead to rendering artifacts.
Changeset: e07207914384 Author:vadim Date: 2014-03-21 14:11 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e07207914384 RT-36235: Zero specular power can lead to rendering artifacts. Reviewed-by: kcr, ckyang Summary: clamp specular power to 0.001 internally. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGPhongMaterial.java
TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'
Hi, I updated my workspace recently, tried to build it and have got the following exception. Any suggestions? FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':web:compileGeneratedWin'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'. -- -- Thanks, Leonid
Re: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'
Are you using gradle 1.8? This looks like a bug we used to have with prior versions of gradle. -- Kevin Leonid Popov wrote: Hi, I updated my workspace recently, tried to build it and have got the following exception. Any suggestions? FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':web:compileGeneratedWin'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'.
Re: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'
Was this gradle 1.8 or a problem with an EA version of JDK8? In any case, update both. If you can't, doing a clean every time should work but that's not the long term answer. Steve On 2014-03-21 5:49 AM, Kevin Rushforth wrote: Are you using gradle 1.8? This looks like a bug we used to have with prior versions of gradle. -- Kevin Leonid Popov wrote: Hi, I updated my workspace recently, tried to build it and have got the following exception. Any suggestions? FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':web:compileGeneratedWin'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'.
[8u] Review request: RT-34950: [Media] JavaFx Player on MAC Crashes Application When Playing Specific Video
Hello, could you please review the following fix: Webrev: http://cr.openjdk.java.net/~anashaty/RT-34950/webrev.00/ http://cr.openjdk.java.net/%7Eanashaty/RT-34950/webrev.00/ Issue: https://javafx-jira.kenai.com/browse/RT-34950 Thank you! Anton.
How to build 64-bit FX ?
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 ?
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: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'
This was a gradle 1.4 bug that is fixed in 1.8: http://issues.gradle.org/browse/GRADLE-2831 Leonid just happened to be running an older gradle. -- Kevin Stephen F Northover wrote: Was this gradle 1.8 or a problem with an EA version of JDK8? In any case, update both. If you can't, doing a clean every time should work but that's not the long term answer. Steve On 2014-03-21 5:49 AM, Kevin Rushforth wrote: Are you using gradle 1.8? This looks like a bug we used to have with prior versions of gradle. -- Kevin Leonid Popov wrote: Hi, I updated my workspace recently, tried to build it and have got the following exception. Any suggestions? FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':web:compileGeneratedWin'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'.
hg: openjfx/8u-dev/rt: Fix for RT-36308 [IMX] Mouse sometimes jumps to edge of screen on first mouse move.
Changeset: 74b46ab976e2 Author:lisa.se...@oracle.com Date: 2014-03-21 10:56 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/74b46ab976e2 Fix for RT-36308 [IMX] Mouse sometimes jumps to edge of screen on first mouse move. Reviewed by dblaukopf. Tested with HelloCursors. ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c
Re: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'
We fail on gradle 1.11. I have filed this bug: https://javafx-jira.kenai.com/browse/RT-36330 I suggest that if we can't fix the bug quickly, we print out a message that we require gradle 1.8 and exit. We should let people override this choice in the properties file. Steve On 2014-03-21 7:47 AM, Kevin Rushforth wrote: This was a gradle 1.4 bug that is fixed in 1.8: http://issues.gradle.org/browse/GRADLE-2831 Leonid just happened to be running an older gradle. -- Kevin Stephen F Northover wrote: Was this gradle 1.8 or a problem with an EA version of JDK8? In any case, update both. If you can't, doing a clean every time should work but that's not the long term answer. Steve On 2014-03-21 5:49 AM, Kevin Rushforth wrote: Are you using gradle 1.8? This looks like a bug we used to have with prior versions of gradle. -- Kevin Leonid Popov wrote: Hi, I updated my workspace recently, tried to build it and have got the following exception. Any suggestions? FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':web:compileGeneratedWin'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'.
Re: [8u] Review request: RT-34950: [Media] JavaFx Player on MAC Crashes Application When Playing Specific Video
Looks good. Approved. On 21.03.2014 17:54, anton nashatyrev wrote: Hello, could you please review the following fix: Webrev: http://cr.openjdk.java.net/~anashaty/RT-34950/webrev.00/ http://cr.openjdk.java.net/%7Eanashaty/RT-34950/webrev.00/ Issue: https://javafx-jira.kenai.com/browse/RT-34950 Thank you! Anton.
Re: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'
I suggest that if we can't fix the bug quickly, we print out a message that we require gradle 1.8 and exit. We should let people override this choice in the properties file. Good idea. We already print a warning if not gradle 1.8 so it would be easy to fail the build instead (perhaps we could also allow 1.9 since that is reported to work). -- Kevin Stephen F Northover wrote: We fail on gradle 1.11. I have filed this bug: https://javafx-jira.kenai.com/browse/RT-36330 I suggest that if we can't fix the bug quickly, we print out a message that we require gradle 1.8 and exit. We should let people override this choice in the properties file. Steve On 2014-03-21 7:47 AM, Kevin Rushforth wrote: This was a gradle 1.4 bug that is fixed in 1.8: http://issues.gradle.org/browse/GRADLE-2831 Leonid just happened to be running an older gradle. -- Kevin Stephen F Northover wrote: Was this gradle 1.8 or a problem with an EA version of JDK8? In any case, update both. If you can't, doing a clean every time should work but that's not the long term answer. Steve On 2014-03-21 5:49 AM, Kevin Rushforth wrote: Are you using gradle 1.8? This looks like a bug we used to have with prior versions of gradle. -- Kevin Leonid Popov wrote: Hi, I updated my workspace recently, tried to build it and have got the following exception. Any suggestions? FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':web:compileGeneratedWin'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'.
Re: [8u] Review request: RT-34950: [Media] JavaFx Player on MAC Crashes Application When Playing Specific Video
Please add your approved comment to the JIRA. Thanks. -- Kevin Kirill Kirichenko wrote: Looks good. Approved. On 21.03.2014 17:54, anton nashatyrev wrote: Hello, could you please review the following fix: Webrev: http://cr.openjdk.java.net/~anashaty/RT-34950/webrev.00/ http://cr.openjdk.java.net/%7Eanashaty/RT-34950/webrev.00/ Issue: https://javafx-jira.kenai.com/browse/RT-34950 Thank you! Anton.
Re: How to build 64-bit FX ?
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
Glass Robot and getSCreenCapture
I have been working on a problem with Robot.getScreenCapture() on a 565 ARM device, and while doing so, encountered a couple of questions which I will bring up: Pixxls getScreenCapture(int x, int y, int width, int height, boolean isHiDPI) I don't seem any real documentation that says how x,y + width,height should be treated when compared to the reality of the Screen. What values of x,y + width,height are reasonable ? I can picture any number of scenarios with them that would result in a box that does not fit within the Screen dimensions. The only implementing code I have seen checks to that the width height are = 1. Can I/Should I handle -x values ? What if the requested bounds exceed the screen ? If we are making assumptions that the requested box is inside the screen then why don't we document that fact and add a check in the Robot class (instead of relying on the native impls). If we are assuming the requested box does not have to lie within the screen bounds - what should the returned values be for the pixels outside the screen ? Pixel Black ? (Currently I think Lens would return 0x instead of 0xff00) My recommendation would be modify the JavaDoc contract to specify that the x,y and x+width, y+height must be within the screen bounds, with an IllegalArgumentException if out of bounds. This would be checked in Robot, prior to calling the native impls. This code is internal API, so I expect the real impact would be on SQE. -- David Hill david.h...@oracle.com Java Embedded Development Socialism is great until you run out of other peoples money -- Margaret Thatcher
Re: Glass Robot and getSCreenCapture
Hi David, I don't think we're making any assumptions. We feed the coordinates to a native API and rely on the OS to do the right thing. In other words, our assumption is that if the box lays (partially or fully) outside of the screen area, then the behavior is undefined. Note that the Screen API in Glass allows its clients to check what coordinates are valid (i.e. belong to a real screen). So whatever your return for pixels outside of screen bounds should be fine. 0x0 or 0xff00 - both look good. However, I agree that a stricter specification and a check might be the best solution. -- best regards, Anthony On 3/21/2014 8:53 PM, David Hill wrote: I have been working on a problem with Robot.getScreenCapture() on a 565 ARM device, and while doing so, encountered a couple of questions which I will bring up: Pixxls getScreenCapture(int x, int y, int width, int height, boolean isHiDPI) I don't seem any real documentation that says how x,y + width,height should be treated when compared to the reality of the Screen. What values of x,y + width,height are reasonable ? I can picture any number of scenarios with them that would result in a box that does not fit within the Screen dimensions. The only implementing code I have seen checks to that the width height are = 1. Can I/Should I handle -x values ? What if the requested bounds exceed the screen ? If we are making assumptions that the requested box is inside the screen then why don't we document that fact and add a check in the Robot class (instead of relying on the native impls). If we are assuming the requested box does not have to lie within the screen bounds - what should the returned values be for the pixels outside the screen ? Pixel Black ? (Currently I think Lens would return 0x instead of 0xff00) My recommendation would be modify the JavaDoc contract to specify that the x,y and x+width, y+height must be within the screen bounds, with an IllegalArgumentException if out of bounds. This would be checked in Robot, prior to calling the native impls. This code is internal API, so I expect the real impact would be on SQE.
hg: openjfx/8u-dev/rt: RT-32459: CMD-BACKSPACE should delete the line to the left of the caret, not the word (Mac)
Changeset: 37b60b405b4b Author:leifs Date: 2014-03-21 10:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/37b60b405b4b RT-32459: CMD-BACKSPACE should delete the line to the left of the caret, not the word (Mac) ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java
hg: openjfx/8u-dev/rt: RT-36314: JavaFX API javadoc has wrong link to JDK docs
Changeset: 8a9062f8c637 Author:kcr Date: 2014-03-21 11:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8a9062f8c637 RT-36314: JavaFX API javadoc has wrong link to JDK docs ! build.gradle
[8u20] post-commit review: RT-36314: JavaFX API javadoc has wrong link to JDK docs
I just pushed the fix for the following bug: JIRA: https://javafx-jira.kenai.com/browse/RT-36314 Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8a9062f8c637 This will allow links to JDK classes to be generated in our API docs. -- Kevin
hg: openjfx/8u-dev/rt: [Accessibility] fix comment format
Changeset: 8c568afe762a Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-03-21 12:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8c568afe762a [Accessibility] fix comment format ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java
Re: *PropertyBase vs Simple*Property
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 ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this,
viewport, (o) - {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
instead of
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
@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;
}
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 InvalidatedSimpleObjectPropertyT extends
SimpleObjectPropertyT {
private final ConsumerInvalidatedSimpleObjectPropertyT
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
ConsumerInvalidatedSimpleObjectPropertyT 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
ConsumerInvalidatedSimpleObjectPropertyT 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 ConsumerInvalidatedSimpleObjectPropertyT
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 who overload invalidated be changed to PropertyBase?
It is unlikely that we'll be able to do anything major here in Java 8 just
because we don't really have Lambda yet that we can play with, and changing
over every property is a big job. Unless we knew it would be a major win. I
would say, if you encounter a Simple* property that has been subclassed, then
we should fix it up as we go to be a PropertyBase* guy instead.
Re: *PropertyBase vs Simple*Property
Cool. What we then need to measure is the impact to dynamic footprint (i.e.:
heap usage). Do the extra 3 fields per property object (bean, name, invalidated
method) have any significant impact? Or are these property instances created so
infrequently that it doesn’t make any real difference?
Richard
On Mar 21, 2014, at 12:53 PM, Tom Schindl tom.schi...@bestsolution.at 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 ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this,
viewport, (o) - {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
instead of
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
@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;
}
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 InvalidatedSimpleObjectPropertyT extends
SimpleObjectPropertyT {
private final ConsumerInvalidatedSimpleObjectPropertyT
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
ConsumerInvalidatedSimpleObjectPropertyT 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
ConsumerInvalidatedSimpleObjectPropertyT 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 ConsumerInvalidatedSimpleObjectPropertyT
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 who overload invalidated be changed to PropertyBase?
It is unlikely that we'll be able to do anything major here in Java 8 just
because we don't really have Lambda yet that we can play with, and changing
over every property is a big job. Unless we knew it would be a major win. I
would say, if you encounter a Simple* property that has been subclassed,
then
Re: *PropertyBase vs Simple*Property
This looks good. I wonder if we should make this (massive) change
before we lambda graphics and controls? Probably doesn't matter. We'll
need a JIRA and someone assigned to it in order to track the work.
Steve
On 2014-03-21 12: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 ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this, viewport,
(o) - {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
instead of
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
@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;
}
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 InvalidatedSimpleObjectPropertyT extends
SimpleObjectPropertyT {
private final ConsumerInvalidatedSimpleObjectPropertyT
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
ConsumerInvalidatedSimpleObjectPropertyT 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
ConsumerInvalidatedSimpleObjectPropertyT 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
ConsumerInvalidatedSimpleObjectPropertyT 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 who overload invalidated be changed to PropertyBase?
It is unlikely that we'll be able to do anything major here in Java 8 just
because we don't really have Lambda yet that we can play with, and changing
over every property is a big job. Unless we knew it would be a major win. I
would say, if you encounter a Simple* property that has been subclassed, then
we should fix it up as we go to be a PropertyBase* guy instead.
Re: *PropertyBase vs Simple*Property
It does seem promising. We'll also need data to show the trade-offs to
help inform whether it is worth making such a massive change.
-- Kevin
Stephen F Northover wrote:
This looks good. I wonder if we should make this (massive) change
before we lambda graphics and controls? Probably doesn't matter.
We'll need a JIRA and someone assigned to it in order to track the work.
Steve
On 2014-03-21 12: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 ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this,
viewport, (o) - {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
instead of
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
@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;
}
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 InvalidatedSimpleObjectPropertyT extends
SimpleObjectPropertyT {
private final ConsumerInvalidatedSimpleObjectPropertyT
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
ConsumerInvalidatedSimpleObjectPropertyT 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 ConsumerInvalidatedSimpleObjectPropertyT
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
ConsumerInvalidatedSimpleObjectPropertyT 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 who overload invalidated be changed to PropertyBase?
It is unlikely that we'll be able to do anything major here in Java
8 just because we don't really have Lambda yet that we can play
with, and changing over every property is a big job. Unless we knew
it would be a major win. I would say, if you
hg: openjfx/8u-dev/rt: RT-36264: SceneBuilder doesn't start since FX 8 u20 b04 [work around for In(Sanity) Testing]
Changeset: 1e3c73548b16 Author:snorthov Date: 2014-03-21 15:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1e3c73548b16 RT-36264: SceneBuilder doesn't start since FX 8 u20 b04 [work around for In(Sanity) Testing] ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/inspector/editors/AutoSuggestEditor.java
Gradle 1.11 (and 1.8) will now fail fast with a clear error [was: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin']
I just pushed a fix for https://javafx-jira.kenai.com/browse/RT-36330
Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27390e79b4cf
There is a bug in gradle 1.11 (already fixed in 1.12-rc1) which would be
intrusive to workaround, so 1.11 is now blacklisted.
The logic is this:
if (gradleVersion != 1.8) {
if (gradleVersion 1.8) fail
else if (gradleVersion == 1.11) fail
else warn
}
You can turn the failures into warnings with gradle
-PGRADLE_VERSION_CHECK=false
-- Kevin
Stephen F Northover wrote:
We fail on gradle 1.11. I have filed this bug:
https://javafx-jira.kenai.com/browse/RT-36330
I suggest that if we can't fix the bug quickly, we print out a message
that we require gradle 1.8 and exit. We should let people override
this choice in the properties file.
Steve
On 2014-03-21 7:47 AM, Kevin Rushforth wrote:
This was a gradle 1.4 bug that is fixed in 1.8:
http://issues.gradle.org/browse/GRADLE-2831
Leonid just happened to be running an older gradle.
-- Kevin
Stephen F Northover wrote:
Was this gradle 1.8 or a problem with an EA version of JDK8? In any
case, update both. If you can't, doing a clean every time should
work but that's not the long term answer.
Steve
On 2014-03-21 5:49 AM, Kevin Rushforth wrote:
Are you using gradle 1.8? This looks like a bug we used to have
with prior versions of gradle.
-- Kevin
Leonid Popov wrote:
Hi, I updated my workspace recently, tried to build it and have
got the following exception. Any suggestions?
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':web:compileGeneratedWin'.
java.lang.ClassFormatError: Invalid Constant Pool entry Type 18
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for
task ':web:compileGeneratedWin'.
hg: openjfx/8u-dev/rt: RT-36330: Gradle 1.11 fails to build JFX
Changeset: 27390e79b4cf Author:kcr Date: 2014-03-21 16:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27390e79b4cf RT-36330: Gradle 1.11 fails to build JFX ! build.gradle ! gradle.properties.template
Re: Gradle 1.11 (and 1.8) will now fail fast with a clear error [was: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin']
Great! There were people getting burned by this at EclipseCon. Luckily,
I remembered this bug and was able to help them but now we don't have to.
Steve
On 2014-03-21 4:15 PM, Kevin Rushforth wrote:
I just pushed a fix for https://javafx-jira.kenai.com/browse/RT-36330
Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27390e79b4cf
There is a bug in gradle 1.11 (already fixed in 1.12-rc1) which would
be intrusive to workaround, so 1.11 is now blacklisted.
The logic is this:
if (gradleVersion != 1.8) {
if (gradleVersion 1.8) fail
else if (gradleVersion == 1.11) fail
else warn
}
You can turn the failures into warnings with gradle
-PGRADLE_VERSION_CHECK=false
-- Kevin
Stephen F Northover wrote:
We fail on gradle 1.11. I have filed this bug:
https://javafx-jira.kenai.com/browse/RT-36330
I suggest that if we can't fix the bug quickly, we print out a
message that we require gradle 1.8 and exit. We should let people
override this choice in the properties file.
Steve
On 2014-03-21 7:47 AM, Kevin Rushforth wrote:
This was a gradle 1.4 bug that is fixed in 1.8:
http://issues.gradle.org/browse/GRADLE-2831
Leonid just happened to be running an older gradle.
-- Kevin
Stephen F Northover wrote:
Was this gradle 1.8 or a problem with an EA version of JDK8? In
any case, update both. If you can't, doing a clean every time
should work but that's not the long term answer.
Steve
On 2014-03-21 5:49 AM, Kevin Rushforth wrote:
Are you using gradle 1.8? This looks like a bug we used to have
with prior versions of gradle.
-- Kevin
Leonid Popov wrote:
Hi, I updated my workspace recently, tried to build it and have
got the following exception. Any suggestions?
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':web:compileGeneratedWin'.
java.lang.ClassFormatError: Invalid Constant Pool entry Type 18
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed
for task ':web:compileGeneratedWin'.
hg: openjfx/8u-dev/rt: Follow-on for RT-36330 to print the supported gradle version on failure
Changeset: 6c7047fd93f0 Author:kcr Date: 2014-03-21 17:15 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6c7047fd93f0 Follow-on for RT-36330 to print the supported gradle version on failure ! build.gradle
Ability to decorate ChangeListener
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
