Ah, sim, concordo mas utilizar toda a quantidade de bibliotecas, frameworks e o legado java diretamente tem um apelo muito grande.
E esperem o invokeDynamic para um JRuby/Jython/Groovy muito mais potente.
Eu acredito na visão do Perl 6, mesmo que o próprio Parrot não tenha engrenado. Uma VM multi-linguagem é o caminho, e se a CLR não fosse da MSFT ela teria se beneficiado disso e ultrapassado Java.
Ok. Entendi que não dá.
Então tem que codificar as propriedades no bean mesmo.
Pelo menos acho que se vc usar uma convenção marota, tipo colocar um underscore na frente dos fields que precisam ser persistidos, por reflection vc consegue pegar esses campos e construir as queries on the fly.
É pior (menos automático) do que ActiveRecord, mas tb não é o fim do mundo até porque o eclipse já faz isso automaticamente pra vc: gera set/get.
[quote=juzepeleteiro]De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.
Não é a mesma coisa que o ActiveRecord.
[/quote]
Não precisa. Da pra usar a CGLib que faz proxy sem interface. A oitava maravilha do mundo em Java.
Olá
cglib is a powerful, high performance and quality Code Generation Library, It is used to extend JAVA classes and implements interfaces at runtime. Hibernate Uses cglib to generate proxies for persistent classes.
O projeto é tocado por 4 pessoas e parece meio devagar. A idéia é muito boa. Ele é usado por alguns frameworks famosos como Hibernate, Spring, dynaop e Nanning.
[]s
Luca
Só um detalhe sérgio & cia. Lembrando que ActiveRecord do Rails nada mais é que uma implementação do pattern Active Record, e esse sim, pode ser implementado em Java. Não com a mesma claresa, é claro, mas pode.
[quote=marcelomartins][quote=juzepeleteiro]De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.
Não é a mesma coisa que o ActiveRecord.
[/quote]
Não precisa. Da pra usar a CGLib que faz proxy sem interface. A oitava maravilha do mundo em Java.[/quote]
Precisa, se não não compila.
[quote=Luca]Olá
cglib is a powerful, high performance and quality Code Generation Library, It is used to extend JAVA classes and implements interfaces at runtime. Hibernate Uses cglib to generate proxies for persistent classes.
O projeto é tocado por 4 pessoas e parece meio devagar. A idéia é muito boa. Ele é usado por alguns frameworks famosos como Hibernate, Spring, dynaop e Nanning.
[]s
Luca[/quote]
Existe uma duzia de outros, assim como o Javassist que agora é da JBoss.
[]s
Jose Peleteiro
O ActiveRecord do rails é uma implementação do ActiveRecord pattern, isso acho que sabemos.
Mas o ActiveRecord do rails, é um pouco mais do que uma simples implementação. Tem todos os act_as e validate…
Mas o que estamos discutindo é se dá para ter um ActiveRecord, igual a o do Rails, com acts_as, mapeamento transparente e etc; No java.
[quote=juzepeleteiro][quote=louds]Thiago, já trabalhei e tive contato a área de TI de algumas empresas grandes, que figuram na Fortune 500 até.
Elas usam Windows, Linux, AIX, Solaris, MainFrame, Tru65, HPUX - na maioria dos casos pelo menos 4 desses SOs. Muito, para uma boa visão de negocios…
Elas tem sistemas web em produção feitos em php, asp, .net, java, perl, ColdFusion e coisas de nicho como Ruby e C++. A maioria tem sistemas no ar feitos em pelo menos cinco dessas tecnologias, sistemas ativos e sofrendo manutenção evolutiva. Uma empresa com uma área de TI com mais 300 funcionários tranquilamente lida com essa diferença. [/quote]
Eu também, alias na maioria delas. E as poucas que conheci que tentavam padronizar uma única tecnologia. Acaba falhando ou gastando horrores em casos aonde aquele tecnologia não era a mais indicada e for teimosia usaram a padronizada.[/quote]
Aí vocês já generalizando de forma que o que eu disse pareça absurdo. Numa empresa grande o suficiente existirão vários departamentos, e cada tecnologia vai depender da necessidade. Se uma equipe presta serviço a um cliente que usa apenas .Net, não tem escolha a não ser usar .Net, a outra poderia usar Java. Mas o que eu quis dizer não foi isso.
Numa equipe onde com uma determinada função é necessário que haja uma direção estabelecida do “para onde ir”, senão vira bagunça. Se cada desenvolvedor trouxer de casa o que bem entende por “melhor” isso dificultará por exemplo a sua substituição futuramente se ele sair da empresa, ou se sair de férias, ou se precisar mudar de projeto. Nunca será possível garantir o que está sendo usado, o que também pode levar a problemas de segurança.
A menos que esteja lidando com uma revolução mundial onde haja realmente um ganho para o negócio em termos práticos, não há problema. Mas apenas por gosto de alguém, para fazer o mais do mesmo, aí é diferente (como é o caso do Ruby).
Numa empresa grande o desenvolvedor não tem controle sobre a infrasestrutura, servidores, etc, para se mudar garantir o correto funcionamento do ambiente para outra plataforma já é trabalho suficiente de “convencimento”. Generalizar a ponto de “use o que der na telha” não bate com o que já vi por aí.
Outra coisa, deve-se levar em consideração a facilidade que as ferramentas propiciam. O “grande” argumento contra o Java parece funcionar apenas se alguém usa o notepad, e expõe 100% das propriedades via get/set (i.e., sem noção de OO), usa o Java 1.4 ou inferior (sim, para efeito de dramatização) e necessariamente se usa EJB 1/2 (o que não é necessário na maioria dos casos).
O ActiveRecord do rails é uma implementação do ActiveRecord pattern, isso acho que sabemos.
Mas o ActiveRecord do rails, é um pouco mais do que uma simples implementação. Tem todos os act_as e validate…
Mas o que estamos discutindo é se dá para ter um ActiveRecord, igual a o do Rails, com acts_as, mapeamento transparente e etc; No java.
[/quote]
A idéia do ActiveRecord é interessante, com o 6 vindo acredito que será mais fácil realmente de implementar.
Agora não é o fim do mundo utilizar as annotations do ejb 3 para persistir. Nada de tão complexo.
Cada plataforma / linguagem tem suas limitações / dificuldades. Claro que a mesma tem de evoluir e é o caso da especificação para o Java 6.
Pessoalmente concodo com o Michael Yuan, seu ponto de vista é bastante coerente.
O aprendizado do Ruby irá beneficiar até a evolução da plataforma e substituir e começar do zero tudo denovo, não sei se é a solução. Lapidar e refinar faz parte de um processo interativo, não tão ágil quanto alguns métodos, risos, mas cíclico você garante qualidade.
Olá
Vejam http://jutopia.tirsen.com/ sobre a diferença de fazer em Java (com iBatis) e em Ruby com ActiveRecord…
[quote=Jon Tirsén, que está portando iBatis para rBatis]
For those of you that doesn’t know what iBatis is: It’s a very simple O/R mapper that allows for complete flexibility when it comes to O/R mapping. It doesn’t make any assumptions about the database at all so can therefor handle virtually any (relational) database schema in existance. This flexibility comes to a cost of course, using iBatis is several times more time-consuming and error prone compared to ActiveRecord.
You should not use iBatis unless you really have to: use ActiveRecord instead. I warn you, do not underestimate how much more work it can be to do manual O/R mapping. Or as Chad Fowler so eloquently put it on Rails Core:
"Jon, I like what you’re doing, but by God I hope I never have to use it." [/quote]
Vejam também o blog do Martin Fowler: EnterpriseRails
[]s
Luca
[quote=pcalcado][quote=marcelomartins][quote=juzepeleteiro]De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.
Não é a mesma coisa que o ActiveRecord.
[/quote]
Não precisa. Da pra usar a CGLib que faz proxy sem interface. A oitava maravilha do mundo em Java.[/quote]
Precisa, se não não compila.[/quote]
Ah? não entendi! Como assim não compila?
Eu não to falando o que eu acho. To falando que eu uso o CGLib pra fazer proxy de classes sem criar as interfaces e funciona muito bem. O CGLib é ninja, e alem de me economizar um trabalhão ainda deixou todo o projeto muito mais limpo e claro (adjetivos que podem ser associados ao ActiveRecord também se comparado ao hibernate).
[quote=pcalcado][quote=marcelomartins][quote=juzepeleteiro]De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.
Não é a mesma coisa que o ActiveRecord.
[/quote]
Não precisa. Da pra usar a CGLib que faz proxy sem interface. A oitava maravilha do mundo em Java.[/quote]
Precisa, se não não compila.[/quote]
Não precisa mesmo. DynAOP faz mixins usando proxy sem que você precise definir interfaces.
Olá
[]s
Luca
[quote=Luca]Olá
[]s
Luca[/quote]
… exatamente porque o Dynaop utiliza o CGLib. 
Ultimamente acho que estou excessivamente disléxico. Preciso melhorar isso 
Criar proxies dinâmicos para classes é uma coisa. Inserir novos métodos é outra. Como é possível compilar o cliente da classe chamando métodos que só são definidos em runtime? Para usar mixins via AOP, o cliente não precisaria fazer cast para o tipo do mixin (que precisaria conter as definições dos métodos)?
Exato. Não esqueçam: Javatem tipagem estática, mudar isso é possível, mas não é Java! Não obedece à JLS.
Ok tudo se resume em:
“Em Java é impossível chamar um método que não foi codificado hardcoded mesmo.”
Of course, vc pode usar reflection para chamar qualquer método no runtime, inclusive um que foi criado vai modificação de byte code ou algo parecido.
Mas vc não vai querer codificar o seu bean assim:
public class Person {
public Object get(String property) {
}
}
Principalmente porque em java tem um monte de coisas que dependem do getter (getUsername, getAge, etc). Expression Language do JSP é uma delas.
Se bem que essa discussão é meio doida, pois se vc não sabe no compile-time quais os campos, então vc não sabe que existe um username, e vc nunca deveria chamar no seu código um getUsername() da vida.
A coisa se resume em: não dá para criar um método no runtime ! Reflection não é um método.
[quote=Thiagosc][quote=juzepeleteiro][quote=louds]Thiago, já trabalhei e tive contato a área de TI de algumas empresas grandes, que figuram na Fortune 500 até.
Elas usam Windows, Linux, AIX, Solaris, MainFrame, Tru65, HPUX - na maioria dos casos pelo menos 4 desses SOs. Muito, para uma boa visão de negocios…
Elas tem sistemas web em produção feitos em php, asp, .net, java, perl, ColdFusion e coisas de nicho como Ruby e C++. A maioria tem sistemas no ar feitos em pelo menos cinco dessas tecnologias, sistemas ativos e sofrendo manutenção evolutiva. Uma empresa com uma área de TI com mais 300 funcionários tranquilamente lida com essa diferença. [/quote]
Eu também, alias na maioria delas. E as poucas que conheci que tentavam padronizar uma única tecnologia. Acaba falhando ou gastando horrores em casos aonde aquele tecnologia não era a mais indicada e for teimosia usaram a padronizada.[/quote]
Aí vocês já generalizando de forma que o que eu disse pareça absurdo. Numa empresa grande o suficiente existirão vários departamentos, e cada tecnologia vai depender da necessidade. Se uma equipe presta serviço a um cliente que usa apenas .Net, não tem escolha a não ser usar .Net, a outra poderia usar Java. Mas o que eu quis dizer não foi isso.[/quote]
Não! Sem essa de que eu estou querendo fazer você parecer um idota que só fala absurdo. Não leia meus textos como se eu estivesse brigando com você para ver quem tem razão. Eu entendo a sua opinião, respeito, só não concordo. E disse que conheço lugares aonde o pessoas dizem: – Aqui só usamos Java (ou o que quer que seja)
E que na minha opinião os caras em muitos projetos, que outra tecnologia seria mais recomendada, gastam mais e não tem tanto sucesso como teriam se adotasem uma tecnologia melhor.
Mas que felizmente, na maioria das empresas que eu conheço, e muitas são empresas enormes (infelizmente não seria ético dizer nomes aqui), não é assim que funciona. No máximo o que acontece é: De preferência para a tecnologia X. Se não fizer tanta diferença use essa.
[quote=Thiagosc]Numa equipe onde com uma determinada função é necessário que haja uma direção estabelecida do “para onde ir”, senão vira bagunça. Se cada desenvolvedor trouxer de casa o que bem entende por “melhor” isso dificultará por exemplo a sua substituição futuramente se ele sair da empresa, ou se sair de férias, ou se precisar mudar de projeto. Nunca será possível garantir o que está sendo usado, o que também pode levar a problemas de segurança.
A menos que esteja lidando com uma revolução mundial onde haja realmente um ganho para o negócio em termos práticos, não há problema. Mas apenas por gosto de alguém, para fazer o mais do mesmo, aí é diferente (como é o caso do Ruby).
Numa empresa grande o desenvolvedor não tem controle sobre a infrasestrutura, servidores, etc, para se mudar garantir o correto funcionamento do ambiente para outra plataforma já é trabalho suficiente de “convencimento”. Generalizar a ponto de “use o que der na telha” não bate com o que já vi por aí.[/quote]
Sim, no cenário em que você está falando é totalmente verdade. Se o cara não tiver um arquiteto de solução que defina qual a melhor tecnologia e arquitetura para aquele projeto e melhor ele pegar uma e ficar com ela pro resto da vida.
Mas, no cenário que eu estou falando, empresas contratam um arquiteto de solução (normalmente de uma consultoria) que faz um estudo do projeto e chega a uma conclusão, que pode ser aquele projeto é melhor em C, eles vão contratar uma consultoria especializada para desenvolver em C. Não estou falando de ter um time que saiba todas tecnologias. Mas chamar o time que sabe aquele que a deve ser usada.
E nem todos os argumentos para essa decisão são técnicas. Coisas como preço, prazo, mão de obrar no mercado, fornecedores, desejos do cliente entre outras são avaliadas.
Não estou falando de ficar mudando a tecnologia de um projeto e etc, nem que qualquer um vem e muda uma coisa. Mas existe um cara, o arquiteto de solução, que têm esse papel e essa capacidade.
Por exemplo, em uma empresa que conheci os caras estavam fazendo um sistema de simulação matemática em Java, por que java era a tecnologia deles. Quando chegamos lá sugerimos que o mesmo fosse feito com auxilo de bibliotecas matematicas, que são normalmente em C ou Fortran. Ele chamaram varias consultorias com skill para fazer isso, selecionamos uma, e foi desenvolvida em C. E de 10 dias de processamento passou para 1 hora (Isso mesmo). Não que o Java seja uma má tecnologia, apenas não era apropriada para isso.
Agora, imagine um projeto, aonde se vai ter 3-5 usuário e é só entrada de dados. E está toda hora sendo mexido. Eu conheco um monte assim, principalmente quando se trata de sistema de entrada de parametros para um sistema de BI. (preço do dolar, meta da empresa para esse mes, coisas do tipo). Eu pergunto: Para que usar Hibernate, JSF, JSP, Struts, EJB? Nessa caso, com um Ruby da vida se vai muuuuuuito mais rápido e eu diria até melhor.
Concordo com você que as ferramentas ajudam, mas a minha principal critica quando ao get/set é a legibilidade do codigo, e não poder fazer um objeto.atributo++ coisa do tipo. Eu gosto de ler um código e entender tudo que ele faz lendo ele. Ai vem aquele monte de get set que não quer dizer nada… sim, get e set me irrita.
Cara, não me leve a mal, eu acho Java do caramba. Mas tem seus pontos fracos (assim como fortes) e adimitir isso é muito bom para qualquer profissional.
[quote=pcalcado][quote=AllMighty]
Como é possível compilar o cliente da classe chamando métodos que só são definidos em runtime?
[/quote]
Exato. Não esqueçam: Javatem tipagem estática, mudar isso é possível, mas não é Java! Não obedece à JLS.
[/quote]
Bah, perfeito. Eu to falando de uma coisa e vocês de outra. Foi mal ai.
Obvio, é impóssivel chamar um método que não está definido na classe. Isso é fato. Java não faz isso.
Quando eu disse que é possivel fazer proxy sem interfaces com o CGLib estav comparando com o sistema de proxy nativo do Java, que usa Interfaces. E o CGLib faz proxy em runtime, ele cria uma nova classe e devolve ela. Tudo em tempo de execução. Mas só os métodos que estão definidos na classe original é que podem ser chamados.
Mas ai tem o seguinte. A gente ta comparando linguagens dinamicas com a tipagem estatica do Java. E isso não pode ser. São coisas diferentes. Comparamos então com o groovy, que pode ser chamado métodos que não existem e todos caem em um método padrão.