search

ldh0826 / snakeyaml

Automatically exported from code.google.com/p/snakeyaml
Apache License 2.0
0 stars 0 forks source link

float primitive with CompactConstructor fails due to floats being Doubles #144

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1.  See attached patch file for modified test case that fails

What is the expected output? What do you see instead?
Expected the object to be created with the float primitive set.  Instead 
SnakeYAML attempts to call the setter with a Double instead and fails.

What version of SnakeYAML are you using? On what Java version?
SnakeYAML 1.10 on Mac OS X Java 1.6.0_29

Please provide any additional information below. (Often a failing test is
the best way to describe the problem.)

Original issue reported on code.google.com by tommy.o...@gmail.com on 8 Mar 2012 at 1:21

Attachments:

GoogleCodeExporter commented 8 years ago 
CompactContructor can work with immutable instances (without empty contructor) 
and this is one of the reasons why CompactContructor is not using flexible 
machinery for JavaBean property recognition (it is using just plain implicit 
types). It would be a major task to make it work as for JavaBeans.
In the meantime, you can always instruct SnakeYAML how to build a particular 
instance.

See the example here:
http://code.google.com/p/snakeyaml/source/browse/src/test/java/org/yaml/snakeyam
l/issues/issue144/FloatPropertyTest.java

Original comment by py4fun@gmail.com on 10 Mar 2012 at 12:04

GoogleCodeExporter commented 8 years ago 
Alex, can you please have a look ?
This can provide some info:
http://code.google.com/p/snakeyaml/source/browse/src/main/java/org/yaml/snakeyam
l/extensions/compactnotation/CompactConstructor.java#153

If you think it is too complex, feel free to close the issue.

Original comment by py4fun@gmail.com on 14 Mar 2012 at 6:04

GoogleCodeExporter commented 8 years ago 
This issue was updated by revision a8b64db3ef92.

Types for properties defined in mapping now resolved in the same way as for 
JavaBean not in CompactNotation
However "8. implicit types do not work for tokens, all the values are always 
Strings" still is true. So properties defined in scalar assumed to be strings.

Original comment by alexande...@gmail.com on 16 Mar 2012 at 11:02

GoogleCodeExporter commented 8 years ago 
It will be delivered in version 1.11

Original comment by py4fun@gmail.com on 19 Mar 2012 at 6:32