Странна грешка при инжектиране на Guice

Имам много странна грешка, когато се опитвам да инжектирам с конструктор с Guice. В конструктора има конкретен ред, както следва:

@Inject
public RoundRobinAssigner(
        ... arguments
        ) {
            ...stuff

    assignments = Sets.synchronizedNavigableSet(Sets.<CountingEntry<String>>newTreeSet());
}

Това се проваля при инжектиране със следното.

1) Error injecting constructor, java.lang.NoSuchMethodError: com.google.common.collect.Sets.synchronizedNavigableSet(Ljava/util/NavigableSet;)Ljava/util/NavigableSet;
  at edu.harvard.econcs.turkserver.util.RoundRobinAssigner.<init>(RoundRobinAssigner.java:46)
  at edu.harvard.econcs.turkserver.util.RoundRobinAssigner.class(RoundRobinAssigner.java:40)
  while locating edu.harvard.econcs.turkserver.util.RoundRobinAssigner

Но ако премахна обвивката Sets.synchronizedNavigableSet(), нещата се инжектират добре.

@Inject
public RoundRobinAssigner(
        ... arguments
        ) {     
            ...stuff

    assignments = Sets.<CountingEntry<String>>newTreeSet();

}

Ясно е, че това е неоптимално, тъй като искам да използвам синхронизирания набор. Има ли някаква причина инструктор, наречен Guice, да се държи по различен начин от нормален? Нито един от тези кодове няма проблеми с компилирането и класът Sets от guava също е зареден, така че нямам представа какво причинява това.


person Andrew Mao    schedule 05.03.2013    source източник


Отговори (1)


Подозирам, че просто виждате проблем, който иначе бихте виждали другаде - основно защото Guice е включен при зареждането на класа чрез отражение, грешката „време на връзката“ за недостъпност на Sets.synchronizedNavigableSet се показва в контекста на Guice вместо в "нормален" конструктор.

synchronizedNavigableSet беше представен само в 13.0 - възможно ли е да компилирате срещу това, но да работите срещу по-стара версия на Guava?

person Jon Skeet    schedule 05.03.2013
comment
Да, това наистина беше проблемът. Две противоречиви декларации на Guava в различни проекти' pom.xml. Eclipse използваше най-новия за компилиране, но изпълнението се подчиняваше на действителните правила на Maven, причинявайки грешката. - person Andrew Mao; 05.03.2013