[
https://issues.apache.org/jira/browse/STORM-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055982#comment-14055982
]
Jungtaek Lim edited comment on STORM-328 at 7/9/14 8:19 AM:
------------------------------------------------------------
I'm also investigating this issue.
Definitely using Utils.getInt() with long value leads problem.
{quote}
System.out.println(new Long(Long.MAX_VALUE));
System.out.println(new Long(Long.MAX_VALUE).intValue());
System.out.println(new Long(Long.MIN_VALUE));
System.out.println(new Long(Long.MIN_VALUE).intValue());
{quote}
prints below
{quote}
9223372036854775807
-1
-9223372036854775808
0
{quote}
(My develop environment is OSX 10.8 with JDK 1.7.0_55.)
Implementation of Long.intValue(), it just type-cast long value to int.
It means type-casting picks lower 4 bytes from long but many situations we
don't intend to.
http://www.myhowto.org/java/60-understanding-the-primitive-numeric-type-conversions-in-java/
was (Author: kabhwan):
I'm also investigating this issue.
Definitely using Utils.getInt() with long value leads problem.
{quote}
System.out.println(new Long(Long.MAX_VALUE));
System.out.println(new Long(Long.MAX_VALUE).intValue());
System.out.println(new Long(Long.MIN_VALUE));
System.out.println(new Long(Long.MIN_VALUE).intValue());
{quote}
prints below
{quote}
9223372036854775807
-1
-9223372036854775808
0
{quote}
(My develop environment is OSX 10.8 with JDK 1.7.0_55.)
Implementation of Long.intValue(), it just type-cast long value to int.
It means type-casting picks lower 4 bytes from long but many situations we
don't intend to.
> Config.java and Utils.get{Int,Long} are not in sync for floating point
> ----------------------------------------------------------------------
>
> Key: STORM-328
> URL: https://issues.apache.org/jira/browse/STORM-328
> Project: Apache Storm (Incubating)
> Issue Type: Bug
> Affects Versions: 0.9.2-incubating, 0.9.1-incubating, 0.9.0.1
> Reporter: Robert Joseph Evans
> Labels: newbie
>
> For most numeric configuration values Config.java has a type of Number
> listed, but the values are parsed using Utils.getInt or Utils.getLong, which
> means if someone gave a floating point number it would pass the
> ConfigValidation, but would blow up when it is used. This is most critical
> for values that Nimbus reads, but would be good to have them consistent
> everywhere.
> We should also check that getInt works properly for numbers that are larger
> then would fit in an integer.
> Either we need to update Utils to be more lenient when looking at doubles, or
> we need to make Config more strict, which may be difficult with the YAML and
> JSON parsing that happens, where ints are often converted into longs.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
