2013-05-06 4 views
0

Sonar говорит: «Производительность - может быть реорганизована в именованный статический внутренний класс. Класс DataServiceImpl $ 2 может быть реорганизован в именованный статический внутренний класс».Sonar Performance - статический внутренний класс Token Token

paramsClass1.add(new TypeToken<List<EntityFieldMap>>(){}.getType()); 

Таким образом, создан статический класс, и он отлично работает, но когда я делаю его общим, он не работает. Посмотрите на этот фрагмент.

import com.google.gson.reflect.TypeToken; 
public class TokenTest 
{ 
    public static class MyInnerClass1<T> extends TypeToken<T> {}; 
    public static class MyInnerClass2<Integer> extends TypeToken<Integer> {}; 

    public static void main(String[] args) 
    { 
     //prints T 
     System.out.println(new MyInnerClass1<Integer>().getType()); 
     //prints Integer which is desired 
     System.out.println(new MyInnerClass2().getType()); 
    } 
} 
+2

В чем вопрос? – unholysampler

+0

Что-то здесь глупо. Это предположение - преждевременная оптимизация, корень всего зла. Вы даже не запускаете его в цикле. Даже если вы это сделали, это не имеет значения, если компилятор действительно глупо (код эквивалентен). –

+0

@JanHudec: Я согласен. Если что-нибудь это может быть проблемой для обслуживания, но я не вижу, как это может быть проблемой «производительности» ... –

ответ

3

TypeToken является особенным, потому что это на самом деле зависит от того анонимного класса. И причина, по которой ваш токен сгенерированного типа не работает, является причиной того, что TypeToken существует в первую очередь! Дженерики будут удалены во время выполнения. Расширение универсального класса с фиксированным параметром типа - это способ обойти это ограничение.

Смотрите JavaDoc of Guava TypeToken (я знаю, что вы говорите о GSON, но использование и функциональность одинакова в обеих библиотеках, и гуавы один имеет лучшую документацию):

Обратите внимание, что это важно, чтобы аргумент фактического типа переносится подклассом. Следующий код неверен, поскольку он только фиксирует переменную типа <T> в сигнатуре метода listType(); в то время как <String> теряется в стирании:

class Util { 
    static <T> TypeToken<List<T>> listType() { 
    return new TypeToken<List<T>>() {}; 
    } 
} 

TypeToken<List<String>> stringListType = Util.<String>listType(); 

Мое предложение: игнорировать это предупреждение для TypeToken (в идеале в автоматическом режиме, в качестве альтернативы вручную путем добавления исключений).

+0

Есть ли другой способ получить тип? – dumper

Смежные вопросы