| Autor |
Mensagem |
|
|
 C*ralho, sono é f*da. Foi mal 
Mas, respondendo a pergunta do Scrabby, e aproveitando pra esticar o assunto, então:
Mas...uh...e se eu quiser "copiar" um objeto, pra poder brincar com ele sem interferir nas outras referências?
Implemente Cloneable!
Ah, e veja também Object .clone().
|
 |
|
|
Paulo Silveira wrote: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
|
|
|
|
Exatamente! Em python dá pra escrever isso numa boa:
|
|
|
|
|
No Java, não existe passagem por valor para objetos, só por referências... logo, tudo que tem numa Collection é referência...
|
|
|
|
Paulo Silveira wrote:eh. enum com metodo eu ainda nao captei a necessidade.
eu soh preciso de enum pra definir umas constantezinhas e tal.
Pois é... coisa estranha... talvez eles estejam criando o novo conceito de EOP (Enum-Oriented Programming  )
Paulo Silveira wrote: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.
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...
Paulo Silveira wrote: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????
Aguardemos as consequências...
|
|
|
|
Paulo Silveira wrote:Poxa. Tem o Hibernate e OJB que fazm persistencia de banco de dados e tem uma LEGIAO de fas. Struts e WebWork nem se fala. E tem mais dois, que nao sei se todo mundo conhece: O AltRMI (versao apacheana do RMI) e o Entreprise Object Broker, baseado no OJB e AltRMI, para confrontar DIRETO o EJB. Apache tambem. Eu amo os nerdzinhos do apache/jakarta!
Pois é, tá cheio de projetos tentando "reinventar melhor" a roda dos EJBs. O Hibernate, por exemplo, resolve muito bem a questão da persistência, aliás, e eu sou fã de carteirinha dele pra usar naqueles casos onde vai ter mais leitura do que escrita no DB. É rápido, e o desenvolvimento, aliado ao XDoclet, WebWork e Velocity, fica uma baba total. Sai mais rápido que muita gente programando em PHP por aí, até.
Agora, que empresa te deixaria começar um projeto usando essas ferramentas? O difícil, em muitos casos, é "vender" alternativas mais simples aos EJBs e JSPs. Tenho experimentado bastante isso tentando vender o peixe do WebWork em empresas que estão pensando em usar o Struts. Impressionante a trabalheira que dá convencer os caras, e olha que o Struts também é free, e também é considerado "alternativo"!
No fim das contas, o pessoal acaba usando a J2EE "bare metal" pq tem medo de bibliotecas e frameworks opensource...tsc tsc...
|
|
|
|
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
|
|
|
|
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:
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
|
|
|
|
Não queria que esse topico se transformasse em um EJB vs Não-EJB, mas já que estamos nesse assunto, vamos a algumas pesquisas interessantes que o pessoal do JBoss tem feito:
- Nem todo mundo precisa de todas as features do EJB: alguns precisam só da persistência, outros precisam do controle de segurança, outros de transações, e por aí vai
- Muita gente nao gosta de desenvolver EJBs por causa do tempo de desenvolvimento (e pela dificuldade de depuração e de se fazer testes automatizados realmente decentes)
- Muita gente gosta de EJBs pq acha eles uma mão na roda
Logo...
Por que não implementar a coisa de uma maneira que qualquer POJO (Plain Old Java Object) possa se "transformar" em EJB, dadas informações suficientes no deployment descriptor? Assim, não mataríamos a herança (EJBs hoje estendem EJBObject, lembram-se?) nem pesaríamos muito no desenvolvedor pra conhecer a semântica de passivação, nem boas partes do life-cycle de um EJB.
Entra o JBoss AOP...
No novo release do JBoss, Marc Fleury, Rickard Oberg & friends não estão pensando só em seguir os padrões da J2EE, mas sim em esticá-los para aceitar o uso, vindo de qualquer POJO, das features que hoje são dadas apenas e EJBs, através da arquitetura de serviços e microkernel do JBoss e uns belos truques de AOP (Aspect-Oriented Programming).
Resultado: tudo o que se queria (bom, eu, pelo menos, queria) na J3EE
PS: Este post foi altamente especulativo. Não estou prometendo nada, e também não tenho nenhuma ligação com o JBoss além de "reles usuário". Mas, definitivamente gostei da idéia, se é que eu a entendi direito, e queria passar pra frente. Então, se eu falei merda, por favor me corrijam 
|
|
|
|
Verdade...
Já cheguei a ver esquemas, todos estranhíssimos, de replicação de sessões no Tomcat quando tive de refatorar um projeto uma vez. A melhor implementação das que vi foi botar um InitializerServlet carregado no startup dos Tomcats, que ficava fazendo a sincronização, mandando as sessões serializadas através de JavaGroups...
|
|
|
|
|
...e quem usa, mas não tem profissionais e ferramentas competentes, está gastando um dinheiro mais violento ainda com tecnologia que não vai ser tão escalável quanto promete... então, aqui vai, de novo, a máxima: People + Tools + Time + QA = Code.
|
|
|
|
|
Oziel, dá pra fazer load balancing no tomcat, sim, replicando sessão e tudo mais. Dêem uma lida nisso aqui: http://216.239.53.100/search?q=cache:s93okXQucBUC:www.ubeans.com/tomcat/+tomcat+load+balancing&hl=pt&ie=UTF-8
|
|
|
|
|
Não existe "modelagem correta"... existem as mais indicadas para cada caso... no seu, especificamente, Active Records parecem ser uma otima ideia, ja que seu codigo fica todo no mesmo lugar...
|
|
|
|
|
Se voce esta fazendo os testes com dois browsers na mesma maquina, pode ser algo maligno com cookies, mas estou só especulando...
|
|
|
|
|
Voce pode testar no Jetty, mas pelo problema que vc disse estar acontecendo, isso é pau no código, nao no web container
|
|
|
|
|
|