Todos sabem e de acordo com a especificacao, toda constante precisa ser tudo em caixa alta, ou seja, tudo em maisculo
Mas…
Por que quando manda implementar um serialVersion para uma classe Serializable, o eclipse nao segue essa convencao?
private static final long serialVersionUID = 1L;
[quote=igor_ks]Todos sabem e de acordo com a especificacao, toda constante precisa ser tudo em caixa alta, ou seja, tudo em maisculo
Mas…
Por que quando manda implementar um serialVersion para uma classe Serializable, o eclipse nao segue essa convencao?
private static final long serialVersionUID = 1L; [/quote]
Pois é… em casa de ferreiro, o espeto é de pau.
Não é o Eclipse que fez esse padrão, está no javadoc da interface Serializable. Esse campo é usado para distinguir versões de uma classe, para serialização e desserialização. Meu palpite é que a convenção foi criada depois da criação da interface, que é uma das mais antigas do Java.
Hum, faz sentido 
O QUE É
Serializable
E
serialVersion
?
Existem inúmeros exemplos de nomeacões fora do padrão no java, o mais clássico é o Hashtable que deveria ser HashTable.
[quote=deniswsrosa]Existem inúmeros exemplos de nomeacões fora do padrão no java, o mais clássico é o Hashtable que deveria ser HashTable.
[/quote]
Na verdade, existem inúmeros exemplos de más práticas no Java. A própria Serializable é exemplo, mas tem Cloneable, também.
[quote=PREGO_NOOB]O QUE É
Serializable
E
serialVersion
?[/quote]
Serializable é uma característica porreta do java: você consegue persistir objetos java (tipo, gravar um objeto em um arquivo, ou mandar pra outro computador) facim facim graças a ele. Procure por isso no google, tem tutorial do java sobre isso…
[quote=asaudate][quote=deniswsrosa]Existem inúmeros exemplos de nomeacões fora do padrão no java, o mais clássico é o Hashtable que deveria ser HashTable.
[/quote]
Na verdade, existem inúmeros exemplos de más práticas no Java. A própria Serializable é exemplo, mas tem Cloneable, também.[/quote]
Agora fiquei curioso… Porque mal exemplo de programação?
[quote=igor_ks]Mas…
Por que quando manda implementar um serialVersion para uma classe Serializable, o eclipse nao segue essa convencao?
private static final long serialVersionUID = 1L;[/quote]
Nem o NetBeans segue.
Também tenho uma dúvida, por que quando vamos instanciar um objeto do tipo AudioClip usamos:
audio = newAudioClip(getClass().getResource("...audio"));Note newAudioClip operador [color=blue]new[/color] junto com o nome da classe, sem espaço, por que :?:
[quote=InicianteJavaHenrique][quote=igor_ks]Mas…
Por que quando manda implementar um serialVersion para uma classe Serializable, o eclipse nao segue essa convencao?
private static final long serialVersionUID = 1L;[/quote]
Nem o NetBeans segue.
Também tenho uma dúvida, por que quando vamos instanciar um objeto do tipo AudioClip usamos:
audio = newAudioClip(getClass().getResource("...audio"));Note newAudioClip operador [color=blue]new[/color] junto com o nome da classe, sem espaço, por que :?:
[/quote]
eu não conheço essa classe…más…
você não esta criando um objeto, no método newAudioClip, em algum ponto deve ter um new (algumObjeto) e ele mesmo te retorna uma nova instancia do objeto
se essa classe é do próprio java, o correto seria isso ai ser um construtor…
ai o new seria separado do AudioClip
[quote=josenaldo][quote=asaudate][quote=deniswsrosa]Existem inúmeros exemplos de nomeacões fora do padrão no java, o mais clássico é o Hashtable que deveria ser HashTable.
[/quote]
Na verdade, existem inúmeros exemplos de más práticas no Java. A própria Serializable é exemplo, mas tem Cloneable, também.[/quote]
Agora fiquei curioso… Porque mal exemplo de programação?[/quote]
Não sei se este é o motivo pelo qual o asaudate citou estas classes como exemplo de más práticas, mas no Effective Java, o Joshua Bloch escreve o seguinte a respeito da interface Cloneable:
No caso da Serializable, ele ainda destaca o seguinte:
Já dá pra ter uma ideia!
[quote=josenaldo][quote=asaudate][quote=deniswsrosa]Existem inúmeros exemplos de nomeacões fora do padrão no java, o mais clássico é o Hashtable que deveria ser HashTable.
[/quote]
Na verdade, existem inúmeros exemplos de más práticas no Java. A própria Serializable é exemplo, mas tem Cloneable, também.[/quote]
Agora fiquei curioso… Porque mal exemplo de programação?[/quote]
Porque Serializable é um péssimo exemplo? Porque Serializable só marca a classe como Serializável, mas os métodos de leitura/escrita dos objetos são completamente externos à interface. Fora que métodos como defaultReadObject e defaultWriteObject não estão especificados nessa interface, criando um grande gap entre o a teoria da computação orientada a objetos, coesão, etc.
O mesmo vale para Cloneable. O método clone() não está definido nessa interface, mas sim, na classe Object. Se você invocar clone() num objeto que não implementa Cloneable, ele vai lançar uma exceção. Te pergunto: porque diabos o método clone não fica em Cloneable, mas sim em Object ?
E tem vários outros exemplos, ainda. Se quiser ver mais, leia o blog do Cameron Purdy. Ele criou uma série de artigos falando sobre vários problemas diferentes presentes nessas nuances do Java. Vale a pena 
[]'s
wagner, no próprio post que você citou o Joshua Bloch faz algumas críticas a forma que o Cloneable e o Serializable foram implementados.
Veja que no Cloneable, ele já ressalta que é um uso muito atípico (um eufismo para idiota) de interfaces.
E no caso do Serializable, ele já é mais explícito sobre o fato dos métodos dos ObjectOutputStreams aceitarem como parâmetro um Object e não um Serializable.
Só para citar mais um exemplo. A classe Color contém constantes de cor em letra minúscula também: Color.red, Color.blue, etc. Mais tarde, quando fizeram as code conventions, inseriram as constantes em maiúsculas: Color.RED, Color.BLUE, etc.
http://docs.oracle.com/javase/7/docs/api/java/awt/Color.html
É normal que com a evolução da linguagem, as classes comecem a apresentar más práticas. Com os anos, programar na linguagem fica cada vez mais periogoso, pois você tem que saber o que é novo e o que é velho (o C++ que o diga).
Por exemplo, hoje em dia, você encontrará diversas implementações de enums em Java através de constantes de inteiros estáticas. Coisas como o método setDefaultCloseOperation do JFrame.
A partir do Java 5, a forma correta e typesafe de implementar enums é através de enums, como as classes do pacote java.synchronized já fazem.
A tendência é que programadores do futuro façam a mesma pergunta que você fez:
“Por que diabos a Oracle não usou enums e fez desse jeito idiota?”
E a resposta é a mesma:
“Por que na época os enums sequer existiam.”
[quote=ViniGodoy]Só para citar mais um exemplo. A classe Color contém constantes de cor em letra minúscula também: Color.red, Color.blue, etc. Mais tarde, quando fizeram as code conventions, inseriram as constantes em maiúsculas: Color.RED, Color.BLUE, etc.
http://docs.oracle.com/javase/7/docs/api/java/awt/Color.html
É normal que com a evolução da linguagem, as classes comecem a apresentar más práticas. Com os anos, programar na linguagem fica cada vez mais periogoso, pois você tem que saber o que é novo e o que é velho (o C++ que o diga).
Por exemplo, hoje em dia, você encontrará diversas implementações de enums em Java através de constantes de inteiros estáticas. Coisas como o método setDefaultCloseOperation do JFrame.
A partir do Java 5, a forma correta e typesafe de implementar enums é através de enums, como as classes do pacote java.synchronized já fazem.
A tendência é que programadores do futuro façam a mesma pergunta que você fez:
“Por que diabos a Oracle não usou enums e fez desse jeito idiota?”
E a resposta é a mesma:
“Por que na época os enums sequer existiam.” :)[/quote]
Pois é. O que levanta a questão que está sendo discutida hoje em dia: até quando o Java tem que ser retrocompatível?
Sim. Para mim o Swing é uma API que precisa urgentemente de revisão.
Uma alternativa que poderiam usar é fazer um Swing 2.0 e criar algum .jar opcional, como um oldSwing.jar com a velharia lá.
Assim, quem precisasse de retrocompatibilidade ainda teria a API velha, mas novos desenvolvedores seriam encorajados a usar o novo.
Sim. Para mim o Swing é uma API que precisa urgentemente de revisão.
Uma alternativa que poderiam usar é fazer um Swing 2.0 e criar algum .jar opcional, como um oldSwing.jar com a velharia lá.
Assim, quem precisasse de retrocompatibilidade ainda teria a API velha, mas novos desenvolvedores seriam encorajados a usar o novo.[/quote]
Mas isso iria acabar gerando novos problemas… o jar com a velharia não ia poder ser incorporado de volta se não ia dar um monte de NoClassDefFoundError. A não ser que se trocassem os nomes dos pacotes, mas aí, seria a mesma coisa que tem se feito hoje em dia, que é a criação dos pacotes javax da vida. Acho que não adianta, é qubrar a compatibilidade mesmo. Aliás, convenhamos: quem precisa de compatibilidade com Java 1.3? Eu já ví gente usando 1.4, mas 1.3 é demais.
[]'s
Tem razão.
O que nunca entendi é porque a Sun não colocou no .jar meta-informação, como a versão do java que foi usado para gera-lo. Eu colocaria até um local para o desenvolvedor indicar a versão do programa.
Assim um mecanismo como o que eu falei poderia mapear o arquivo de velharias automaticamente, como o flash faz.
Mas o que é essa retrocompatibilidade traz de prejuízo real ao java?
Em outros ambientes que vejo quebrarem a compatibilidade é comum ficarem usando uma versão antiga por não poderem atualizar.
Conheço vários projetos em .NET, por exemplo, que estão no 2.0 ainda, pois parece que há quebra nas novas versões.
Em Python também me parece, que a versão usada na maioria dos lugares é a 2.x. Acho que a 3.x não é compatível com a 2.
Com esse negócio do Java não conseguir rodar duas versões de uma mesma classe na mesma VM, acho que seria um tiro no pé.
Colocar @Deprecated já não é uma boa ferramenta para estimular as melhores práticas em código novo?
EDIT: Em Scala, que é uma linguagem relativamente nova, a quebra de compatibilidade já me parece ser uma grande fonte de reclamações.
Me parece que você precisa garantir que todas as libs utilizadas sejam compiladas na mesma versão do seu código.
Em médio prazo acho que isso se torna inviável.
Só marcar como deprecated causa uma explosão de métodos duplicados.
Por exemplo, você teria que criar um novo setDefaultCloseOperation. Algo como setDefaultCloseAction, que recebesse um enum.
O código interno das classes começa a ter que fazer malabarismos para suportar o antigo e o novo e, por consequencia, fica mais complexo e sujeito a erros.
Eu acho que o deprecated tem que ser uma solução para algumas versões. Por exemplo, poderiam dizer que um método é cortado após estar deprecated por 10 anos. Um warning é gerado durante o deprecation, e os programadores devem se preocupar, no longo prazo, a resolve-lo.
Além disso, acho que falta deprecated em muita coisa no Java, como nos métodos do Vector que são suplicados com list (addElement, por exemplo).