Mudando um construtor param classe tipo quebras em outro frasco

Question

Eu tenho a seguinte classe em um frasco comum:

public class Common 
{
  public Common(List list)
  {
    ...  
  }  
}

Eu, então, mudar o parâmetro de construtor de uma List a um Collection da seguinte forma:

public class Common 
{
  public Common(Collection collection)
  {
    ...
  }
}

A reconstrução do frasco comum e rodando o sistema provoca uma NoSuchMethodError em qualquer classe dependente quando se invoca o construtor até que eu recompilar essa classe.

Eu tenho algumas idéias que está causando isso, ao longo das linhas de como o construtor é obrigado no bytecode da classe dependente, mas não tenho 100% de certeza.

Por favor, alguém pode lançar alguma luz sobre o que está acontecendo aqui?

Atualização

Eu tenho feito posteriormente um teste rápido e deu uma olhada no bytecode:

Compiled from "Client.java"
public class Client extends java.lang.Object{
public Client();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void main(java.lang.String[]);
  Code:
   0:   new #2; //class ArrayList
   3:   dup
   4:   invokespecial   #3; //Method java/util/ArrayList."<init>":()V
   7:   astore_1
   8:   new #4; //class Common
   11:  dup
   12:  aload_1
   13:  invokespecial   #5; //Method Common."<init>":(Ljava/util/List;)V
   16:  pop
   17:  return

}

Como Tom disse, e como você pode ver na linha 13, o construtor exata é obrigado em tempo de compilação.

Você aprende algo novo a cada dia: -)

Answer 1

resolve javac exatamente qual método ou construtor para chamar em tempo de compilação. Isso não ocorre em tempo de ligação. Como a assinatura de construtor mudou, a etapa que liga não pode encontrar o método solicitado e, portanto, gera um erro. Você pode corrigir o erro, proporcionando construtores - um que leva uma Collection outro List. Mais tarde, pode ser adicionado um construtor tomar um Iterable.

Note, tipos genéricos não fazem parte da assinatura, para aqueles pode ser alterado, embora ainda mantendo a compatibilidade binária. Ambos os tipos de parâmetros e de retorno formam parte da assinatura para métodos (retornos covariantes causar métodos sintéticos de ponte a ser criado).

Há um grande agradável seção no JLS definir exatamente o que constitui alterações compatíveis binários.

Answer 2

Você está importando os corretos classes de lista e coleção? ou seja java.util.List e java.util.Collection?

Answer 3

Eu acho que poderia ser um problema com a versão da biblioteca. Tem certeza de que não há outra versão do commons algum lugar biblioteca de outra pessoa no mesmo contexto?