Re: Cleaning up Control codebase - How to deal with StyleableProperty cast

2014-05-02 Thread Tom Schindl
Hi,

Yes if i turn on this unnecessary type cast warning in Eclipse I get
that as well.

Currently the only solution to get around with ANY warning suppression I
found is to use an intermediate variable.

Tom

On 28.04.14 23:57, Jonathan Giles wrote:
 This seems to look fine - IntelliJ still complains about an unnecessary
 cast, but it is better than having an unchecked cast.
 
 I'm happy for this to be done, but I think it would be best to get David
 Grieve's +1 first too.
 
 Thanks for your help so far - it is making the JavaFX code base much
 nicer. I've just switched IntelliJ to make warnings far more obvious to
 me, so I'll be trying to keep on top of them also.
 
 -- Jonathan
 
 On 29/04/2014 9:33 a.m., Tom Schindl wrote:
 Hi,

 I've been cleaning up the warnings inside the controls code base and one
 of the warnings left (beside many generic problems in the *View-classes)
 is the casting from *Property to *StyleableProperty.

 final StyleablePropertyBoolean prop =
 (StyleablePropertyBoolean)focusTraversableProperty();
 now I think I found a way to get away with out an unchecked cast warning
 by writing

 final StyleablePropertyBoolean prop =
 (StyleablePropertyBoolean)(WritableValueBoolean)focusTraversableProperty();

 Anyone having a better idea?

 Tom
 



Re: Cleaning up Control codebase - How to deal with StyleableProperty cast

2014-05-01 Thread Tom Schindl
Hi Jonathan  David,

do you have any opinion on this? I would spend some time tomorrow to
bring down the warning count.

Maybe we should use the Styleable*Property cast when we control both the
API  implementation and reside to the more save
(StyleablePropertyBoolean)(WritableValueBoolean) e.g. if we don't
e.g. because code is owned by the graphics module?

One could naturally look at this from another angle and say the Syleable
interface should have been shown in the API but I guess this not going
to change so we need to live with casts and the implementation detail.

Tom

On 30.04.14 15:39, Tom Schindl wrote:
 Hi,
 
 On 29.04.14 14:35, David Grieve wrote:
 I've found that this works:

 final StyleableBooleanProperty prop =
 (StyleableBooleanProperty)focusTraversableProperty();

 
 Right i can confirm that.
 
 The problem is that we are then relying even more on the fact the
 upstream code does not change. If someone because of what ever reason
 decides to replace the StyleableBooleanProperty through a custom
 implementation StyleablePropertyBoolean we get broken.
 
 In case of focusTraversableProperty() we are even crossing module
 boundaries in this case which worries me a bit.
 
 Tom
 



Re: Cleaning up Control codebase - How to deal with StyleableProperty cast

2014-05-01 Thread David Grieve
I don't have a strong opinion, other than a preference for having it 
done one way in all cases. So it seems 
(StyleablePropertyBoolean)(WritableValueBoolean) would be the way to go.


On 5/1/14, 12:25 PM, Tom Schindl wrote:

Hi Jonathan  David,

do you have any opinion on this? I would spend some time tomorrow to
bring down the warning count.

Maybe we should use the Styleable*Property cast when we control both the
API  implementation and reside to the more save
(StyleablePropertyBoolean)(WritableValueBoolean) e.g. if we don't
e.g. because code is owned by the graphics module?

One could naturally look at this from another angle and say the Syleable
interface should have been shown in the API but I guess this not going
to change so we need to live with casts and the implementation detail.

Tom

On 30.04.14 15:39, Tom Schindl wrote:

Hi,

On 29.04.14 14:35, David Grieve wrote:

I've found that this works:

 final StyleableBooleanProperty prop =
(StyleableBooleanProperty)focusTraversableProperty();


Right i can confirm that.

The problem is that we are then relying even more on the fact the
upstream code does not change. If someone because of what ever reason
decides to replace the StyleableBooleanProperty through a custom
implementation StyleablePropertyBoolean we get broken.

In case of focusTraversableProperty() we are even crossing module
boundaries in this case which worries me a bit.

Tom





Re: Cleaning up Control codebase - How to deal with StyleableProperty cast

2014-05-01 Thread Jonathan Giles

I agree with David. Let's go that way and see where things end up.

As always, thanks Tom for being relentless in pushing this forward.

-- Jonathan

On 2/05/2014 1:27 p.m., David Grieve wrote:
I don't have a strong opinion, other than a preference for having it 
done one way in all cases. So it seems 
(StyleablePropertyBoolean)(WritableValueBoolean) would be the way 
to go.


On 5/1/14, 12:25 PM, Tom Schindl wrote:

Hi Jonathan  David,

do you have any opinion on this? I would spend some time tomorrow to
bring down the warning count.

Maybe we should use the Styleable*Property cast when we control both the
API  implementation and reside to the more save
(StyleablePropertyBoolean)(WritableValueBoolean) e.g. if we don't
e.g. because code is owned by the graphics module?

One could naturally look at this from another angle and say the Syleable
interface should have been shown in the API but I guess this not going
to change so we need to live with casts and the implementation detail.

Tom

On 30.04.14 15:39, Tom Schindl wrote:

Hi,

On 29.04.14 14:35, David Grieve wrote:

I've found that this works:

 final StyleableBooleanProperty prop =
(StyleableBooleanProperty)focusTraversableProperty();


Right i can confirm that.

The problem is that we are then relying even more on the fact the
upstream code does not change. If someone because of what ever reason
decides to replace the StyleableBooleanProperty through a custom
implementation StyleablePropertyBoolean we get broken.

In case of focusTraversableProperty() we are even crossing module
boundaries in this case which worries me a bit.

Tom







Re: Cleaning up Control codebase - How to deal with StyleableProperty cast

2014-04-30 Thread Tom Schindl
Hi,

According to Eclipse Compiler people we probably found a bug in javac.
They cited the following paragraph from the spec:

 A cast from a type S to a parameterized type (§4.5) T is unchecked
unless at least one of the following is true:
*  S : T
*  All of the type arguments (§4.5.1) of T are unbounded wildcards
*  T : S and S has no subtype X other than T where the type arguments
   of X are not contained in the type arguments of T. 

Tom

On 29.04.14 00:00, Jonathan Giles wrote:
 IntelliJ says the following:
 
 =
 Unchecked cast: 'javafx.beans.property.BooleanProperty' to
 'javafx.css.StyleablePropertyjava.lang.Boolean'
 
 *JDK 5.0 only.*
 Signals places where an unchecked warning is issued by the compiler, for
 example:
 
 |void f(HashMap map) {
   map.put(key, value);
 }
 |=
 
 Perhaps the 'JDK 5.0 only' is significant? I honestly don't know
 
 -- Jonathan
 
 On 29/04/2014 9:57 a.m., Tom Schindl wrote:
 Hi,

 Interesting is that only the Eclipse Java Compiler shows a warning.
 javac is fine with original code.

 Let me see what the Eclipse compiler guys have to say about that!

 Tom

 On 28.04.14 23:33, Tom Schindl wrote:
 Hi,

 I've been cleaning up the warnings inside the controls code base and one
 of the warnings left (beside many generic problems in the *View-classes)
 is the casting from *Property to *StyleableProperty.

 final StyleablePropertyBoolean prop =
 (StyleablePropertyBoolean)focusTraversableProperty();
 now I think I found a way to get away with out an unchecked cast warning
 by writing

 final StyleablePropertyBoolean prop =
 (StyleablePropertyBoolean)(WritableValueBoolean)focusTraversableProperty();

 Anyone having a better idea?

 Tom

 



Re: Cleaning up Control codebase - How to deal with StyleableProperty cast

2014-04-30 Thread Tom Schindl
Hi,

On 29.04.14 14:35, David Grieve wrote:
 I've found that this works:
 
 final StyleableBooleanProperty prop =
 (StyleableBooleanProperty)focusTraversableProperty();
 

Right i can confirm that.

The problem is that we are then relying even more on the fact the
upstream code does not change. If someone because of what ever reason
decides to replace the StyleableBooleanProperty through a custom
implementation StyleablePropertyBoolean we get broken.

In case of focusTraversableProperty() we are even crossing module
boundaries in this case which worries me a bit.

Tom