2014-12-16 11 views
6

Mam danych Object Access napisane przy użyciu jOOQ i zwraca raczej skomplikowany typ podpis:Czy istnieje ograniczenie złożoności typu, które można wywnioskować na podstawie wartości Lombok?

Map<Record, Result<Record14<String, Integer, String, String, String, String, String, String, Integer, String, Boolean, Boolean, Integer, Boolean>>> result = create.... 

próbowałem go zastąpić Lombok "val"

val result = create.... 

To działa, gdy biegnę/skompilować z Eclipse ... Przy próbie kompilacji ciągu Gradle, otrzymuję:

UpdatesDAO.java:307: error: incompatible types 
      .fetchGroups(key); 
         ^
    required: val 
    found: Map<Record,Result<Record14<String,Integer,String,String,String,String,String,String,Integer,String,Boolean,Boolean,Integer,Boolean>>> 

Czy ktoś powiedz mi, dlaczego to działałoby w Gradle dla prostszych typów, ale nie dla bardziej złożonych typów? Mam inne miejsca w tym samym projekcie, które wyglądają mniej więcej tak:

val records = dao.getDatastoreById(id); // Returns a type of List<Datastore> 

i działają dobrze, nawet gdy skompilowany z Gradle ... Czy ja czegoś brakuje?

FYI: wersja Lombok = 1.14.8 wersja Gradle 2.2.1

Próbowałem Lombok == 1.14.6 wersja Gradle 2.2.0

Próbowałem również z zarówno Java 8 oraz Java 7, zarówno OpenJDK i Oracle JDK

+0

Pytanie: Dlaczego wymagacie czternaście typów generycznych? To jest zapach kodu bardziej niż cokolwiek innego ... – Makoto

+2

Przypuszczam, że musiałbyś to opisać z osobami jOOQ i sposobem, w jaki robią interakcje z bazami danych ... Bez względu na to, czy jest to zapach kodu, nie ma większego sensu, będzie działać podczas kompilacji z Eclipse i nie będzie działał podczas kompilacji z Gradle. –

+0

@Makoto: Często te typy są używane tylko w scenariuszach w płynnym API jOOQ i są wnioskowane przez kompilator –

Odpowiedz

1

odpowiedź jest konflikt między DSL i Lombok jOOQ za .. The jOOQ DSL ma metoda "val", co spowoduje konflikt, gdy importowane statycznie:

import static org.jooq.impl.DSL.val; 

Jeśli używasz tej metody "val" poprzez statyczny import, przerwie ona implementację "val" lomboka. Usunięcie tego statycznego importu i użycie "DSL.val()" rozwiązało problem.

Więcej informacji na stronie: https://code.google.com/p/projectlombok/issues/detail?id=762

Powiązane problemy