Novas features do JDBC4

Nossa, olha que legal o uso de annotations aqui. Seria uma pista do que pode ser feito com annotations + compiler API? Gerar implementações on the fly mais facilmente?

http://www.artima.com/lejava/articles/jdbc_four3.html

Não existe nada de especial nisso, tão apenas usando uns dinamic proxies para executar as queries e fazer o binding. Não tem nada de geração de código envolvido, tão pouco a compiler api.

Esse exemplo do JDBC4 é util apenas para aplicações simples e quick’n dirty, deixar as queries no código é uma idéia muito, muito ruim.

[quote=louds]Não existe nada de especial nisso, tão apenas usando uns dinamic proxies para executar as queries e fazer o binding. Não tem nada de geração de código envolvido, tão pouco a compiler api.

Esse exemplo do JDBC4 é util apenas para aplicações simples e quick’n dirty, deixar as queries no código é uma idéia muito, muito ruim.
[/quote]

Aquela interface MyQueries com o annotation não é implementada e passada para o desenvolvedor que chamou o “createQueryObject”?

Assim ele só precisa iterar sobre o DataSet, e se fizer alterações apenas mandar atualizar com o DB?

Eu devo ter desaprendido a ler, pois eu juro que o javadoc diz isso:

Eu acho isso muito interessante sim!!! Diminui o código enormemente.

É claro que ele tem que criar uma implementação “concreta” da interface internamente, mas como o louds já disse, essa “implementação concreta” é apenas um proxy, ele não gera um arquivo .java e compila ele em momento nenhum, tanto que o JDBC 4 é vai ser completamente compatível com versões anteriores do Java.

Já é possível fazer tudo o que a Compiler API oferece hoje, usando Javassist, ASM e CGLIB, ela só vai facilitar um pouco mais a vida dos desenvolvedores.

[quote=Maurício Linhares]É claro que ele tem que criar uma implementação “concreta” da interface internamente, mas como o louds já disse, essa “implementação concreta” é apenas um proxy, ele não gera um arquivo .java e compila ele em momento nenhum, tanto que o JDBC 4 é vai ser completamente compatível com versões anteriores do Java.
[/quote]

Eu não disse que um arquivo “.java” seria gerado! Eu disse que uma classe seria gerada on the fly baseada na interface com annotation, e isso era um uso interessante da “Compiler API”, daí o “criação de um implementação concreta”.

Eu deduzi o uso da compiler API, pelo fato de gerar uma implementação concreta on the fly! Não olhei o código. Mas enfim, é perfeitamente possível com Annotations e Compiler API fazer coisas assim, que nos poupem trabalho, gerando classes on the fly. Got it?

A interface é criada com métodos arbitrários definidos pelo desenvolvedor! Como ela pode retornar um objeto que implemente essa interface, que retornará os métodos especificados por você, sem gerar uma classe “on the fly”?

Depois ainda falam que trazer as linguagens de computador para “mais próximas das naturais” é uma coisa boa! Pessoas falando a mesma língua nem conseguem se entender!!

[quote=Maurício Linhares]
Já é possível fazer tudo o que a Compiler API oferece hoje, usando Javassist, ASM e CGLIB, ela só vai facilitar um pouco mais a vida dos desenvolvedores.[/quote]

Onde eu disse que não era possível?

BTW, e por que não fizeram isso antes?

Esse é o trabalho de um proxy, ele vai criar um “fake object” que implementa toda aquela interface, mas na verdade, todos os métodos vão ser enviados pra um InvocationHandler que vai decidir o que vai fazer ou não com aquela invocação de método.

O código que faz isso provavelmente lê a definição da interface (lá pelo Interface.class), vè todos os métodos que tem a annotation @Query, cria uma estrutura que guarde os nomes dos métodos com as suas respectivas queries e finalmente cria um proxy que tenha um InvocationHandler que responde gerando as queries pelo método chamado.

[quote=thiagosc] Onde eu disse que não era possível?

BTW, e por que não fizeram isso antes?[/quote]

Não fizeram o que?

[quote=Maurício Linhares]
Esse é o trabalho de um proxy, ele vai criar um “fake object” que implementa toda aquela interface, mas na verdade, todos os métodos vão ser enviados pra um InvocationHandler que vai decidir o que vai fazer ou não com aquela invocação de método.

O código que faz isso provavelmente lê a definição da interface (lá pelo Interface.class), vè todos os métodos que tem a annotation @Query, cria uma estrutura que guarde os nomes dos métodos com as suas respectivas queries e finalmente cria um proxy que tenha um InvocationHandler que responde gerando as queries pelo método chamado.[/quote]

Tanto trabalho para repetir o que eu disse! Um objeto será criado! E eu apenas deduzi o uso da Compiler API para criá-lo on the fly, o que não é impossível.

Eu disse “o como” internamente!?

Um objeto será criado implementando a interface que contém as annotations. Parece que falo grego, cara…

[quote=Maurício Linhares]

Não fizeram o que?[/quote]

Do que estamos falando?

Você tem as seguintes opções:

  • Fizeram um bolo de fubá;
  • Fizeram café;
  • Fizeram nada, ficaram lendo blogs o dia inteiro;
  • Fizeram a implementação desses recursos no JDBC;
  • n.d.a.

Thiago, você afirmou que a implementação faz uso da compiler API. O fato é que esse tipo de coisa é tranquilamente feita usando DP. Olha a implementação de referencia da J2SE, ela usa DP.

Se você não sabe o que são Dynamic Proxies, tudo bem. Só que sua atitude que se você não sabe, logo não existe é digna de um sensacionalista.

Ademais, ficar fanfarreando sobre um software que não foi nem lançado se quer, é coisa digna de fanboy. Caia na real, quando falamos de enterprise não podemos nos dar ao luxo de ficar adotando qualquer coisa que um moleque leu um artigo no final de semana e achou bonito.

Empresas sérias tem processos bem definidos para adotar novos softwares, por isso que muitas grandes corporações então ainda iniciando o processo de homologação do java 5. Ou seja, esse tipo de atitude de fanboy não resolve nenhum problema real de empresas reais que entregam software reais.

[quote=louds]Thiago, você afirmou que a implementação faz uso da compiler API. O fato é que esse tipo de coisa é tranquilamente feita usando DP. Olha a implementação de referencia da J2SE, ela usa DP.
…[/quote]

Cara, você concluiu isso tudo (tudo até o fim, apenas economizei espaço) a partir desse pedaço de texto?

Eu jamais afirmei 90% do que você citou na sua mensagem. Apenas citei a Compiler API porque esse assunto já foi levantado em outros tópicos.

A sua atitude nessa última mensagem foi digna de uma criança de 5 anos fazendo birra. É incrível o quão baixo xiitas conseguem chegar.

Eu achei interessante o JDBC 4. Já tenho acompanhado a JSR há um tempinho e o trabalho é interessante. Sobre a forma como os objetos são criados on-the-fly, o louds está certo: usa-se dynamic proxies e não a compiler API, pois esta não estará (necessariamente) disponível para ser usada em uma JRE:

Sem comentar o overhead para se compilar uma classe a cada novo acesso ao banco de dados.

Isso levantaria os cabelos de muita gente que teima em usar JDBC puro em sistemas de missão critica em Java, SIM eles existem … :mrgreen:

É apenas um exemplo, isso pode ser usado para várias coisas.

[quote=louds]Não tem nada de geração de código envolvido, tão pouco a compiler api.
[/quote]

Bom isso não tem muito a ver com o tópico, mas eu não concordo com essa afirmação. Mesmo que código fonte não é gerado (e a compiler API não é usado), código (na forma de bytecode) é sim gerado dinámicamente para conseguir a funcionalidade do Dynamic Proxy.

[]s,
Sami

[quote=Sami Koivu][quote=louds]Não tem nada de geração de código envolvido, tão pouco a compiler api.
[/quote]

Bom isso não tem muito a ver com o tópico, mas eu não concordo com essa afirmação. Mesmo que código fonte não é gerado (e a compiler API não é usado), código (na forma de bytecode) é sim gerado dinámicamente para conseguir a funcionalidade do Dynamic Proxy.

[]s,
Sami[/quote]

Bem, até aonde eu sei no caso de Dynamic Proxy não é gerado Bytecode não, aonde você leu que é gerado?

[quote=juzepeleteiro][quote=Sami Koivu][quote=louds]Não tem nada de geração de código envolvido, tão pouco a compiler api.
[/quote]

Bom isso não tem muito a ver com o tópico, mas eu não concordo com essa afirmação. Mesmo que código fonte não é gerado (e a compiler API não é usado), código (na forma de bytecode) é sim gerado dinámicamente para conseguir a funcionalidade do Dynamic Proxy.

[]s,
Sami[/quote]

Bem, até aonde eu sei no caso de Dynamic Proxy não é gerado Bytecode não, aonde você leu que é gerado?[/quote]

Olá,

Bom eu não li (alias, não leio bastante). Apenas deduzi. Como é que você consegue um comportamento dinámico assim sem gerar bytecode?

Dei uma olhada na implementação da sun com ReJava e a classe sun.misc.ProxyGenerator tem a cara de quem gera bytecode, sim.

Mas ok, não li isso em lugar nenhum e não posso absolutamente garantir que seja um fato.

[]s,
Sami

Sami, depende da versão. A partir da 1.5, os DP são classes geradas usando o BCEL, ou seja, o bytecode é escrito diretamente.

Na 1.3 e 1.4 era um pouco diferente, a JVM tinha um suporte interno p/ isso, que é até que simples de implementar.

Voltando ao assunto do post original, quando eu bati o olho nisso, a criação da lógica para lidar com tudo JDBC mais o DataSet, imaginei “componentes Swing com databing”.

Embora isso já seja feito de outras formas e acredito uma solução ter sido cogitada para a versão 7, é um exemplo do tipo de melhoria incremental que facilita a vida do desenvolvedor.

Nem tudo no mundo é missão crítica e Enterprise, e essa é uma das críticas ao Java que acredito serem corretas. Imagina uma aplicação desktop que use algum pequeno DB, tipo um cliente de e-mail para guardar dados de contatos, ou um jogo de computador, para que botar “Enterprise” no meio disso?

Swing -> JDBC4 -> JavaDB (?)
Swing -> JDBC4 -> JavaDB (?) -> scripting para determinadas partes (?)

Coisas que hoje podemos fazer muito mais facilmente.

Na minha opinião não há razão para o Java não ser fácil quando precisa ser fácil, e robusto quando precisa ser robusto.

Outra coisa foi o uso de Annotations para gerar esse objeto. Não seria tão fácil assim nas versões anteriores à 5. Isso é sinal de evolução, e a nossa vida é facilitada enormemente.

Conclusão:

  • O Java pode ser fácil e o JDBC não é uma API para “se ter lá mas nunca usar”.

  • A visão “Enterprise only” foi o que permitiu que a Microsoft conquistasse tanto mercado de servidores dos Unix. Acredito que o mesmo tipo de pensamento pode ser aplicado ao Java.

  • Não é necessário criar um objeto a cada query. Cria-se um, e usasse os DataSets para manipular a informação após isso.

Enfim, não entendi o por quê do chilique de algumas pessoas. Isso é o “Grupo de usuários Java” ou não? Se eu postasse isso num fórum de .Net ou Ruby eu entenderia que eu estaria errado, mas esse é o lugar correto para tais coisas.

[quote=Thiagosc]Voltando ao assunto do post original, quando eu bati o olho nisso, a criação da lógica para lidar com tudo JDBC mais o DataSet, imaginei “componentes Swing com databing”.
[/quote]

Java Delphi Swing … só voce mesmo pra ter umas ideias destas. :roll:

Mas databinding é ruim? É mais fácil codificar todos os acessos ao DB e popular uma JTable ou outras widgets na unha??? :shock: Se for ruim para o Java, então é novidade para mim pois isso facilita muito o desenvolvimento de aplicações desktop.

Acho que fazer direto com o banco seria um pouco sim, já que estaria misturando apresentação com acesso e escrita de dados no bd… ou estou errado?

Mas uma coisa que seria interessante seria fazer isso ao invés de direto com o banco, com um java bean. Por exemplo…

Pessoa pessoa = new Pessoa(); JTextField nome = new JTextField(); nome.setData("${pessoa.nome}");

Aí passaria esse java bean pro objeto criado/proxie dinâmico/sei lá o que que vem pra você… [edit] e salvaria ele no bd

Que tal?

flw