You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Bruno P. Kinoshita (JIRA)" <ji...@apache.org> on 2017/04/23 01:25:04 UTC

[jira] [Commented] (MATH-1413) Add generics to Frequency

    [ https://issues.apache.org/jira/browse/MATH-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980205#comment-15980205 ] 

Bruno P. Kinoshita commented on MATH-1413:
------------------------------------------

Any objections for this? Otherwise I will review the code once more, and prepare to merge in the next days.

> Add generics to Frequency
> -------------------------
>
>                 Key: MATH-1413
>                 URL: https://issues.apache.org/jira/browse/MATH-1413
>             Project: Commons Math
>          Issue Type: Bug
>            Reporter: Bruno P. Kinoshita
>            Assignee: Bruno P. Kinoshita
>            Priority: Minor
>              Labels: generics
>             Fix For: 4.0
>
>
> The Frequency class has no generic types, but creates an internal TreeMap, with keys with the type `Comparator<?>`. Then whenever you add or get values from the TreeMap, it will throw CCE if you pass a key value with a different type from the others stored in the map.
> {code}
> Frequency f = new Frequency();
> // Okay
> f.addValue("Ola");
> // Key 12, type Integer, does not match String type. CCE, wrapped in a Math exception
> f.addValue(12);
> {code}
> And even a simpler example without Math classes to help outlining the issue.
> {code}
> TreeMap<Integer, String> map = new TreeMap<>();
> int key = 1;
> map.put(key, "One");
> // Okay
> map.get(100);
> // TreeMap will try to call 1.1#compareTo against each Key it contains, which can result
> // in a CCE here.
> map.get(1.1);
> {code}
> It is not clear how we could compare the key type to the given v value. Checking if the map is not empty, and then checking the type of the first key doesn't sound very elegant (and not sure if it would be a valid solution).
> A better solution could be to add generics to the class, breaking the current contract (i.e. not allowing three types, boxing to longs, etc), but on the bright side, it won't use CCE as a normal workflow, nor need suppress warnings annotations any more.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)