j2se 1.5

public class Foo <A, B, C>{

    private A a;
    private B b;
    private C c;

    public Foo(){
    }

    public A getA(){
       return a;
    }

    public void setA(A a){
       this.a = a;
    }

 //getters e setters

}

public static void main(String args[]){

    Foo<String, Integer, Date> foo = new Foo<String, Integer, Date>();
    foo.setA("Daniel");
    foo.setB(2); // aqui é feito auto-boxing, i.e., o tipo primitivo int se torna um objeto Integer
    foo.setC(new java.util.Date());

}

Tem outras coisinhas interessantes, como tipos covariantes, mas isso é um pouquinho mais complicado. Vou tentar reunir tudo isso em um artigo e depois a gente publica aqui.

“Daniel Quirino Oliveira”:

Tem outras coisinhas interessantes, como tipos covariantes, mas isso é um pouquinho mais complicado. Vou tentar reunir tudo isso em um artigo e depois a gente publica aqui.

Generics não são covariantes.

Pois eh, tiraram isso de ultima hora

Pois eh, tiraram isso de ultima hora :(

Não creio!!! Que chato!!

Mas para o povo não boiar na conversa, tipos covariantes permitiriam que métodos sobre-escritos pudessem retornar tipos diferentes do método original. Por exemplo:

public class Mamifero implements Animal{

      private Mamifero instance = null;

      private Mamifero(){         
      }

      public Mamifero get(){
           if (instance == null)
               instance = new Mamifero(); //sem discussões sobre Singleton... :P
           return instance;
      }

}

public class Elefante extends Mamifero{

      private Elefante instance = null;

      private Elefante(){         
      }

     public Elefante get(){
           if (instance == null)
               instance = new Elefante(); //sem discussões sobre Singleton... :P
           return instance;
     }

}

Se você tentar compilar o código acima, você vai obter um erro, porque o método sobre-escrito não possui a mesma assinatura do método original, incluindo o tipo de dado retornado. Mas, se o povo na JCP não tivesse mudado de idéia, este código iria compilar muito bem em J2SE 1.5. E isso se chama tipo covariante.

Olá

O uso indiscriminado de generics pode fazer com que o código fique bem mais dificil de ler e manter. Vejam o exemplo abaixo:

List<String> gls = new LinkedList<String>();
gls.add("mais um");
List<List<String>> glls = new List<List<String>>();
glls.add(gls);
. . . . .

O código de algumas collections vai ficar mais limpo e principalmente com melhor possibilidade de verificações em tempo de compilação. Há outros casos de bom uso de generics, mas tenho até medo do que um programador de cabeça confusa pode fazer.

Não entendo bem porque a Sun resolveu investir na inclusão de tipos parametrizados no Java ao invés de consertar de vez as classes com erro como javax.comm ou outras que podem ser melhoradas. Nesta linha para mim seria melhor incluir AOP, pelo menos para padronizar as implementações.

O J2SDK 1.4 realmente veio melhorado com a inclusão de java.nio. Já o 1.5 promete generics coisa que eu posso muito bem viver sem.

[]s
Luca

Concordo com vc, Luca…se a intencao da Sun era fazer Java chegar aos 10 milhoes de desenvolvedores, nao eh adicionando mais complexidade a sintaxe que ela vai conseguir, como no caso dos generics… :roll:

Sobre AOP, ainda ta muuuuuuuuuito cedo pra padronizar qualquer coisa… melhor deixar a evolucao natural rolar por mais alguns anos

Alias, ja deu uma brincada com o Groovy? Quanto mais eu uso, mais eu tou gostando

“Luca”:

Olá

O uso indiscriminado de generics pode fazer com que o código fique bem mais dificil de ler e manter. Vejam o exemplo abaixo:

List<String> gls = new LinkedList<String>();
gls.add("mais um");
List<List<String>> glls = new List<List<String>>();
glls.add(gls);
. . . . .

O código de algumas collections vai ficar mais limpo e principalmente com melhor possibilidade de verificações em tempo de compilação. Há outros casos de bom uso de generics, mas tenho até medo do que um programador de cabeça confusa pode fazer.

Não entendo bem porque a Sun resolveu investir na inclusão de tipos parametrizados no Java ao invés de consertar de vez as classes com erro como javax.comm ou outras que podem ser melhoradas. Nesta linha para mim seria melhor incluir AOP, pelo menos para padronizar as implementações.

O J2SDK 1.4 realmente veio melhorado com a inclusão de java.nio. Já o 1.5 promete generics coisa que eu posso muito bem viver sem.

[]s
Luca

Hmmmm, alguns comentários:
:arrow: Códigos ruins e ilegíveis como estes são muito mais facilmente criados com as features atuais. Portanto, descordo que generics vão tornar seu código um lixo. Se você comparar o seu código com generics com um código similar usando as features atuais, não há dúvidas de que o código SEM generics são zilhões de vezes mais ilegíveis e “error-prone” (deus!! alguém consegue aportuguesar isso?!).
:arrow: Sobre a inclusão de características de AOP, acho que isso é um assunto muito delicado. Qual implementação dos conceitos de AOP vai ser usada como base para padronização: AspectJ, AspectWerkz, JBoss AOP, …? Além do mais, a bolha do AOP ainda está inflando; deixe-a estourar primeiro e ver quem sobrevive disso. Aí sim teremos algumas poucas implementações mais maduras e que, talvez, possam servir de exemplo para uma RI para a JCP.

Sem mais…

Só um P.S: “error-prone” => que tende a erros

Código ruim é a coisa mais fácil de se conseguir em QUALQUER linguagem, mas o caso é que com o uso de generics (bom ou mal), vai ser de certa forma mais difícil introduzir alguns erros sutis que antes só eram achados em runtime (ClassCastExceptions malditas em Collections, por exemplo). Ou seja, generics tornam seu codigo menos suscetivel a erros (pronto, Daniel, taí teu aportuguesamento). Isso, ao custo de um pouco mais de sintaxe, até que não parece muito, mas eu não me sentiria nada confortável em aprender a trabalhar com generics caso estivesse vindo de uma linguagem retardada (leia-se VB ou Delphi). Ou seja, dado o objetivo da Sun, me pareceu estranho adicionar generics ao Java.

Falou tudo, melhor do que eu tentei dizer no post anterior

Código ruim é a coisa mais fácil de se conseguir em QUALQUER linguagem, mas o caso é que com o uso de generics (bom ou mal), vai ser de certa forma mais difícil introduzir alguns erros sutis que antes só eram achados em runtime (ClassCastExceptions malditas em Collections, por exemplo). Ou seja, generics tornam seu codigo menos suscetivel a erros (pronto, Daniel, taí teu aportuguesamento). Isso, ao custo de um pouco mais de sintaxe, até que não parece muito, mas eu não me sentiria nada confortável em aprender a trabalhar com generics caso estivesse vindo de uma linguagem retardada (leia-se VB ou Delphi). Ou seja, dado o objetivo da Sun, me pareceu estranho adicionar generics ao Java.

Quem vem de VB/Delphi tem outras preocupações antes de aprender a usar generics: tem que aprender OOP antes de tudo (isso se o fulano não [precisar aprender a programar direito). Então, aprender ou não generics é um mero detalhe, na minha opinião.