No serverside saiu uma entrevista com o Joshua Bloch , nomazinho carimbado de java na sun. Ele tem um livro MUITO bom, o effective java, e esta atrelado a jsr 201, que colocar foreach, autobxing, etc na linguagem. ta bem interessante.
http://www.theserverside.com/events/videos/JoshuaBloch/transcription.html
Fiquei REVOLTADO dele nao ter citado o Gilad Bracha, que eh o cerebro por tras dessas jsrs principais do java 1.5 (a 14 e 201, que mudam a linguagem)
autoboxing? já basta uns ClassCastException que vivem rolando por aí, agora vão inventar de colocar autoboxing…
entao
classcastingexception vai diminuir consideravelmente com generics
e o autoboxing vai ajduar alguns preguicosos. eu nao acho bacana, e com certeza o pior de todos eh o static import. credo.
Po, eu gostei do static import…eu geralmente uso poucas constantes no meu codigo, mas quando eu preciso usar, geralmente elas passam de 100. A tecnica que eu vinha usando até agora pra evitar aquela poluição desgraçada no código era mover todas as constantes pra uma interface e implementar ela na classe em que me interessasse usar as constantes muito frequentemente. Com o static import, não só isso acabou, mas aquele código tipo:
vira:
[code]import static eg.UserFinderUtils.findUserByLogin;
…
User user = findUserByLogin("cv");[/code]
Achei mais legível, mas isso é puramente questão de gosto, claro 
E, afinal, se tá bom, precisa mudar, ou os vendedores de IDEs não ganham dinheiro 
[]'s
-cv
Fica parecendo que tudo pertence a mesma classe com com o static import… meio melequento
Generics rulez total, autoboxing eh bem como o paulo disse: soh pros preguicosos, pq nao ha uma necessidade real ( se evitar milhares de casts se enquadra nisso heheh )
Rafael
Pois eh, vai do gosto… entao a gente pode ficar aqui discutindo isso por dias e nao vai chegar a conclusao nenhuma
Mas… e as enums, hein? ninguem comentou delas, tadinhas… Eu achei as enums da Tiger bem interessantes…mas, porra, enum com métodos!? Aí a coisa já ficou meio pesada, e com certeza vai ter um monte de babaca por aí abusando delas… afinal, tudo que é poderoso também é mal-usado alguma hora
Ate parece que a Sun ta fazendo com o Java o que a MS fez com o .NET: “copiando”… enumerations em .NET eh meio estranho ( principalmente pra quem ta aconstumado com C ), e em Java ta igualmente estranho… mas de qq maneira, vai agradar ( mta? ) gente.
Rafael
eh. enum com metodo eu ainda nao captei a necessidade.
eu soh preciso de enum pra definir umas constantezinhas e tal.
mas sou a favor
e foreach? soh tenho medo de como vai ficar a sincronizacao disso. vai ficar meio obscuro. e vai chegar uma epoca que ninguem mais vai saber pra que serve um tal de Iterator.
Ei. Lembram que apareceu uma discussao de colcoar JDO naa JSE, e um de vcs ateh falou q o Gosling queria tirar JDBC? Entao, tao agrupando JDO na JSE em alguns lguares do site da sun (bugtracker eu vi!). seeerrraaaa???
[quote=“Paulo Silveira”]eh. enum com metodo eu ainda nao captei a necessidade.
eu soh preciso de enum pra definir umas constantezinhas e tal.
[/quote]
Pois é… coisa estranha… talvez eles estejam criando o novo conceito de EOP (Enum-Oriented Programming ;))
[quote=“Paulo Silveira”]e foreach? soh tenho medo de como vai ficar a sincronizacao disso. vai ficar meio obscuro. e vai chegar uma epoca que ninguem mais vai saber pra que serve um tal de Iterator.
[/quote]
A grande maioria, se nao todos, dos iterators é fail-fast, então sincronização não é muito um problema… mas, porra, os caras implementam for-each e não implementam for-else e while-else… que saco! Sério, ninguém alguma vez precisou de um for-else ou while-else, quando quisesse que determinado código executasse caso o loop não chegasse a rodar? O Python por exemplo tem isso e é uma puuuuuta mão na roda às vezes…
Aguardemos as consequências… :shock:
while-else eh nova pra mim… tipo
while (1 > n) {
// ...
}
else {
// damn
}sinistro, nao?! :mgreen:
mas ate ai da pra contornar com um simples if() antes do while() ( apesar de ficar meio tosco… )… ah, ja sei… um while() no estilo try-catch:
while (1 > n) {
// ... blah
}
noMatch {
// bloh
}hehehehehe
Rafael
Exatamente! Em python dá pra escrever isso numa boa:
#note aqui outra coisa interessante, sintaxe pra collections!
cars = ['Ka','Fiesta','Palio','Corsa','Celta','Gol']
# outra construcao bem legal, apesar de confusa :)
c = [x for x in cars if x[1].upper()=='C']
print "Carros começados em 'C':"
for i in c:
print i
else:
print "Nenhum"entao. os iterators de todas collections j2 sao fail fast. mas quero dizer, e qdo eu quiser sincronizar vou ter de fazer na mao como sempre,. e vai ficar feio dar um synchronized em um foreach, porque o cara vai ter de se lgiar q tem uma colelction la, mas tambem poderia ser um array.
tipo, como vou saber que o foreach ta puxando um iterator ou uma enumeration? espero que saia na notificacao
legal isso do python, mas eh muito “perl”. da a ideia pra MS que eles colocam no C#, HUAUHAUHAUH.
Nem precisa, já existe Python pra .NET: http://www.activestate.com/Products/Visual_Python/
PS: E pra Java também: http://www.jython.org
Generics como vai ser na 1.5 foi a pior das besteiras que ja fizeram em nome de ter ‘backward compatibily’.
Ela juntou as desvantagens de ambos modelos, com/sem generics, e ainda piorou, pra melhorar ainda mais so falta autounboxing pra fechar a festa.
Sem querer puxar a sardinha pro lado da MS, mas a implementacao de generics em c# vai ser infinitamente melhor.
Primeiro, ja nao basta ter feito errado na primeira vez, repetiram denovo a mesma besteira, tipos covariantes que nao deveriam ser, como arrays. Pra quem nao sabe, me refiro ao fato de 1 array de referencias poder ser downcasted para array de uma superclasse do tipo da referencia, ex: Integer[] x; Number[] y = x;
Depois o fato da tipagem dos generics ser fraca, pq qualquer coisa faz vc perder essa informacao, devido a covariancia dos tipos genericos, veja 1 exemplo VALIDO do uso de generics:
List x = new ArrayList();
List y = x; //toda informacao de tipagem acabou de ir pro espaco
List<Class> z = (List<Class>)y; //pior de tudo isso nao gera execessao
z.add(String.class); //e isso tb funciona
Ou seja, que acreditou que Generics vai atenuar erros envolvendo CastCastExceptions no uso de Collections se enganou, serao menos, mas alguns poucos vao ser realmente complexos de serem encontrados, dive o exemplo acima.
Outra era a espectativa de um ganho consideravel em performance por poder especializar em tipo primitivos, oque nao vai poder e agora com autoboxing, maioria vai deixar de reclamar pq agora List.add(1) funciona.
A unica coisa boa dos generics eh a opcao de poder definir contrains pros tipos a serem usados.
Tem alguma coisa errada com o seu exemplo, louds… não estou vendo nenhum problema com o que está sendo feito: vc criou uma ArrayList sem tipagem generica, atribuiu uma nova referencia a ela tambem sem tipagem, e depois fez um cast pra List<Class> e adiciou o objeto Class que é membro da classe String. Sério, onde está o mal nisso?
Corto meus dedos se existir backward compatibility. Seu cliente tera de baixar um pequeno “.net framework” de 30 megas novamente.
Generics em c# soih existe em uma pagina de research, assim como o aspect c#. Quero ver acontecer.
louds, o GRANDE problema do seu codigo eh que List<QualquerClass> e List sao da MESMA classe. Se voce der um getClass, vai te devolver o mesmo objeto para as duas… Entao voce pode fazer o casting na buena.
O problema seria se voce fizesse o contrario
List list = new ArrayList<String>;
list.add(new Itneger(1)); // OPS, nao to colocando stringvai compilar, mas vai dar ClassCast qdo rodar.
na hora de compilar isso, se voce usar -warnunchecked, ele vai te dar um toque que voce pode estar fazendo burrada mais pra frente, ja que sua lista soh aceita string, e vc ta falando q ela pode aceitar object agora.
ele eh covariante porcausa do backward.
As vezes upward compatibility deve ser quebrada (VM da 1.4 nao rodar codigo da 1.5) pra poder fazer o negocio direito.
No caso do C# provavelmente vao tomar esse sacrificio.
Porem não é necessario se em vez de mudar a semantica e os metadados das classes para implementar generics fosse feito simplesmente name mangling das classes.
Ou seja, pra 1 classe generica X, quando compilada em modo de compatibilidade geraria 1 classe por tipo primitivo e outra p/ referencias com runtime check (X__int, X__byte, X__long, etc)…
Ou seja, supondo que eu esteja usando ant para controlar a compilacao do projeto, seria apenas adicionar 1 flag p/ gerar codigo com suporte legado e pronto. Minha aplicacao iria automagicamente rodar numa VM que nao conhece generics e ainda assim teria a oportunidade de ter generics como deveriam ser…
quando ao meu exemplo:
List<String> x = new ArrayList<String>();
List y = x; //toda informacao de tipagem acabou de ir pro espaco
List<Class> z = (List<Class>)y; //pior de tudo isso nao gera execessao
z.add(String.class); //e isso tb funcionaPelo que eu entendi da especificação a ultima linha funcionaria sem gerar excessoes. Caso der throw, vai causar muita confusao porque de repente codigo que funcionava vai começar a dar throw sem motivo algum aparente.
Claro, esse codigo funciona. Mas voce perdeu ai a caracteristca especifica da sua Lista generica, e com uma opcao ao GJ, (-warnunchecked, e isto nao esta na jsr, voce precisa rodar exemplos para achar), ele vai te dar um toque, que eh algo nocivo, ja que a partir daquele moemento voce vai poder colocar objetos de outro tipo la dentro.
Afinal, shared memory pra JIT e JARs vai entrar na J2SE 1.5? Não consigo achar uma fonte definitiva sobre o assunto :?
Ah, outra: teremos NIO2 na Tiger Vejam aqui:
http://www.jcp.org/en/jsr/detail?id=203
legal oque a NIO.2 promete oferecer, mas nao achei no site alguma referencia de como vai ser. vai teu suporta a exatamente qual modelo de io assincrona? IOCP e Overlapped IO do windows ou AIO e Sig IO do unix?
Se vc quer usar 1 JVM com shm, usa MAC OSX, pq na tiger nao vai rolar nao…