Java 1,6 -> 1,8, то же стирание ошибки компиляция

Question

Я портирование моего Java приложения от 1,6 до 1,8, а компилятор недоволен методами getAbstractTransactionCriteria() в следующем коде:

public abstract class AbstractTransaction ... 
public class TemplateTransaction extends AbstractTransaction ... 
public class Transaction extends AbstractTransaction ... 

abstract class AbstractTransactionCriteria {...} 
class TransactionCriteria extends AbstractTransactionCriteria {...} 
class TemplateCriteria extends AbstractTransactionCriteria {...} 

TransactionCriteria getAbstractTransactionCriteria(Class<Transaction> c) {...} 
TemplateCriteria getAbstractTransactionCriteria(Class<TemplateTransaction> c) {...} 

Компилятор говорит мне два метода имеют одно и то же стирание, которое я могу принять, потому что я видел в другом месте, что вещи внутри угловых скобок заменяются компилятором Object.

Аргументы c существуют только для достижения полиморфизма (они не используются в телах методов), и это отлично работает в Java 1.6.

Что нужно сделать для достижения того же результата в 1,8?

Answer 1

Если вы можете изменить прототипы функций, и аргументы не используются, кроме как для определения типа возврата, будет ли следующая работа для вас?

TransactionCriteria getAbstractTransactionCriteria(Transaction c) {...} 
TemplateCriteria getAbstractTransactionCriteria(TemplateTransaction c) {...} 

В качестве альтернативы вы можете использовать разные имена функций и не принимать аргументы. Например,

TransactionCriteria getAbstractTransactionCriteria() {...} 
TemplateCriteria getAbstractTemplateCriteria() {...} 

Answer 2

Почему бы не использовать дженерики для этого? Примерно так:

public <T extends AbstractTransactionCriteria> T getAbstractTransactionCriteria(Class<T> c) {} 
// or 
public <T extends AbstractTransactionCriteria> T getAbstractTransactionCriteria(T t) {} 

Таким образом, вам нужен только один метод. Теперь мне известно, что оба метода могут быть совершенно разными (контент мудрый). Хотя даже вы можете просто проверить пройденный тип аргумента и соответственно выполнить действия.

Edit:
Я упомянул статическую PlaceHolder для поддержки полиморфизма. В принципе, если вы видите оба подхода выше, один запрашивает объект класса, а другой запрашивает экземпляр (обычно менее идеальный, так как вы вызываете этот метод для создания экземпляра, а не для одного).

Если вы не хотите использовать genericTypes, как описано выше, вы также можете сделать что-то вроде этого:

abstract class AbstractTransactionCriteria {...} 

// SubClass layout 
class TransactionCriteria extends AbstractTransactionCriteria { 
    // dummy instance doing nothing. 
    public static final TransactionCriteria type = new TransactionCriteria(); 
} 

class TemplateCriteria extends AbstractTransactionCriteria { 
    // dummy instance doing nothing. 
    public static final TemplateCriteria type = new TemplateCriteria(); 
} 



// method layout 
TransactionCriteria getAbstractTransactionCriteria(TransactionCriteria t) 
{...} 

TemplateCriteria getAbstractTransactionCriteria(TemplateCriteria t) 
{...} 


// Call methods 
TransactionCriteria transaction = getAbstractTransactionCriteria(TransactionCriteria.type); 
TemplateCriteria transaction = getAbstractTransactionCriteria(TemplateCriteria.type); 

Как вы можете видеть, таким образом, это своего рода можно использовать ваш «старый макет. Хотя, если это единственный способ, я бы defenitly посоветовал вам перепроектировать ваш текущий шаблон, так как его defenitly не идеально. (как упоминалось ранее, вы можете рассмотреть возможность использования разных имен для каждого метода, так как они возвращают разные результаты, чем предлагает их метод в этом случае)