Java Specification Request, ou simplesmente JSR. Quem trabalha com Java sabe o que essas letrinhas significam. Ou pelo menos deveriam saber.
Qualquer coisa que você vê no Java possui uma JSR. Claro, também existem JSRs que não vingaram ou mesmo que estão obsoletas, substituídas por versões mais novas. Existem JSRs muito limitadas e simples, já outras são verdadeiras obras de arte. Algumas, de tão complexas, precisam ser divididas em várias outras, como a do Java EE. Estas são conhecidas como especificações Umbrellas, ou guarda-chuvas.
JSRs em foco
Ao olharmos uma JSR, notamos que ela não tem nada demais; elas são "apenas" documentos de texto simples que solicitam a criação de um padrão para alguma coisa e, em um segundo momento - após inúmeras discussões e possivelmente anos de brigas entre os diversos integrantes do comitê - documentos que definem o padrão solicitado.
Implementar uma JSR, todavia, pode ser uma tarefa herculóide. Não vou entrar nesse mérito, mas sim, apenas, elencar as JSRs que eu tenho interesse, ou melhor que as telas de cadastro têm interesse.
JSRs relativas às telas de cadastro
227 : A Standard Data Binding & Data Access Facility for J2EE - Provê as bases para construção do famoso binding de componentes de tela e objetos de dados. Focada no Java EE (ex J2EE). É uma especificação de 2003 e à ela são relacionadas as JSRs 114 (JDBC Rowsets), 127 (primeira versão da JSF) e 221 (JDBC 4). Quanto às telas de cadastro, podemos dizer que essa JSR é um Norte para efetuar a ligação dos controles da tela e os objetos de dados (e negócio) que contém a informação.
252: JavaServer Faces 1.2 - Define como criar aplicações web através de componentes, tal como é feito em sistemas desktop: o programador deveria poder ter uma IDE visual para, via drag and drop, montar a tela. Essa especificação define quais são os componentes, como eles podem ser ligados, arrumados na tela e a semântica de sessão, configuração, etc. Enfim, ela é grande. Talvez por esse motivo, ela é uma expansão de algo anterior, a JSR 245 (JSPs) e a JSR 127 (JSF 1.1). Utilíssima para as telas de cadastro porque define como fazer univocamente as coisas na web. Em outras palavras, é assim que se constrói interfaces web para Java. Essa é parte do Java EE 5, definida pela JSR Umbrella 244.
269: Pluggable Annotation Processing API - Essa a osmose não me atingiu e só fiquei sabendo dela pelo artigo do Danny Coward sobre novas features do Mustang. Serve para trabalhar com anotações via parsing no código-fonte do sistema. Por exemplo, quem vai criar um plugin para editores de código pode ser beneficiar muito dela. Quem conhece a ferramenta Apt (Annotation Processing Tool) do Java Tiger pode considerar essa JSR com a mesma coisa, mas agora com uma API e um comportamento mais transparente e extensível. Para as telas de cadastro, considero essa API uma coisa fundamental para o sistema de configuração baseada em histórico e plugin de edição do Merlin. São relacionadas as JSR 175 (anotações) e 14 (genéricos).
296: Swing Application Framework - Assim como a web ganhou servlets controladores e um conjunto de informações de deployment padronizadas (os web-descriptors), o Swing também vai ganhar um padrão para suas actions, tratamento de sessão, gerenciamento de preferências e outras coisas. É essa a JSR responsável por isso. Para as telas de cadastro, tudo de bom: poderemos (talvez) ter um consenso em como fazer várias coisas, desde políticas de gerenciamento de objetos em memória (e o vínculo deles com os controles de tela - um PresentationModel, por exemplo, só ganharia com isso) até recursos i18n.
223: Scripting for the Java Platform - Quem já usa o BeanShell (JSR 274) sabe a mão na roda que ele pode ser. Embora o Merlin já suporte ele, com o advento dessa JSR teoricamente Java poderá suportar qualquer linguagem de scripting. Por padrão o Java 6 virá com a implementação Mozilla Rhino, o que indica que scripts JavaScript (e outros) poderão interagir com objetos Java dentro da aplicação, mesmo as desktop. Para as telas de cadastro, uma flexibilidade extrema, abrindo possibilidades semelhantes às oferecidas pelos programadores VBA.
222: Java Architecture for XML Binding (JAXB) 2.0 - Ela é um seguimento da antiga JSR 31 (Java XML Data Binding) e a idéia dela é permitir o trabalho (criação, uso e manipulação) sobre arquivos XML de forma transparente. Ao usá-la, você sua impressão é que está trabalhando com objetos Java (Javabeans) que, ao final da sessão de trabalho, serão persistidos em arquivos XML. Muito rápida se comparada à Serialização Java. Para as telas de cadastro, considero útil para persistência de estados intermediários de sessões de usuário ou preferências (claro, eu sei que temos a API prefs para isso e agora também a JSR 296 que promete bastante) É esperar para ver.
224: Java API for XML-Based Web Services (JAX-WS) 2.0 - E aqui a parte dos webservices. Com essa JSR, estamos convergindo esforços para acesso a webservices e a interação com eles. Atuando em sincronia com a JSR 222 (JAXB) e com os padrões SOAP 1.2, WSDL 1.2, essa JSR promete facilidades no desenvolvimento e evolução de serviços para web. Assim, recursos como a abstração de mapeamento de objetos recebidos via JAX-RPC para objetos Java e vice-versa, podem atuar em conjunto com features de compilação on demand de classes e recursos de engenharia de bytecodes (BCEL, ASM, etc.). Na prática, vejo um futuro como uma aplicação Java conectando-se em um webservice (feito em .NET, por exemplo) e gerando stubs e classes em tempo de execução e com elas inicializando os dados e exibindo-os na IHC do usuário. Um mundo com conectividade total. Para as telas de cadastro, dou a dica: Um sistema baseado no Merlin pode conectar-se em um webservice qualquer (feito em .NET, de novo!) para obter dados. O JAX RPC traz esses dados e gera das classes Java em tempo de execução junto com o trabalho de mapeamento do JAXB. Essas classes vão para a árvore de classloaders do sistema. O Merlin lê essas classes e gera a tela de cadastro para elas, já inicializando os dados recebidos. O usuário pode, então editar esses dados. Dados alterados, o sistema faz o caminho inverso, sendo que no fim do trajeto um outro webservice recebe os dados (automaticamente mapeados) e persiste em uma base qualquer. Legal, né? Também acho :-)
295: Beans Binding - Essa é ótima. Pelo menos é o que eu imagino que os desenvolvedores desktop deveriam pensar. A idéia é ligar controles de tela e objetos de dado astravés de uma coisa como a Expression Language (EL) usada pelos programadores JSF. Não está no request da especificação, mas acho que também deveria estar disponível um mecanismo de validação e invocação de ações para os controles. No Merlin, eu fiz um esquema de Agentes para isso, como na Eiffel. Essa JSR é crítica ao meu ver, pois centraliza inúmeros pontos que possuem tratamentos a la vonte pelos programadores: desde patterns como o famigerado PresentationModel até códigos ad hoc sobre listeners como o PropertyChangeListener. Para as telas de cadastro? Um ponto único de trabalho para gerenciar a ligação entre os controles de tela e os objetos do sistema.
Bom, como disse, são JSR às pampas. E não estão aqui todas as que considero ligadas às telas de cadastro. Apenas listei as que vieram à cabeça no momento. A dica que deixo é: Mantenham-se atentos às JSRs.
Qualquer coisa que você vê no Java possui uma JSR. Claro, também existem JSRs que não vingaram ou mesmo que estão obsoletas, substituídas por versões mais novas. Existem JSRs muito limitadas e simples, já outras são verdadeiras obras de arte. Algumas, de tão complexas, precisam ser divididas em várias outras, como a do Java EE. Estas são conhecidas como especificações Umbrellas, ou guarda-chuvas.
JSRs em foco
Ao olharmos uma JSR, notamos que ela não tem nada demais; elas são "apenas" documentos de texto simples que solicitam a criação de um padrão para alguma coisa e, em um segundo momento - após inúmeras discussões e possivelmente anos de brigas entre os diversos integrantes do comitê - documentos que definem o padrão solicitado.
Implementar uma JSR, todavia, pode ser uma tarefa herculóide. Não vou entrar nesse mérito, mas sim, apenas, elencar as JSRs que eu tenho interesse, ou melhor que as telas de cadastro têm interesse.
JSRs relativas às telas de cadastro
227 : A Standard Data Binding & Data Access Facility for J2EE - Provê as bases para construção do famoso binding de componentes de tela e objetos de dados. Focada no Java EE (ex J2EE). É uma especificação de 2003 e à ela são relacionadas as JSRs 114 (JDBC Rowsets), 127 (primeira versão da JSF) e 221 (JDBC 4). Quanto às telas de cadastro, podemos dizer que essa JSR é um Norte para efetuar a ligação dos controles da tela e os objetos de dados (e negócio) que contém a informação.
252: JavaServer Faces 1.2 - Define como criar aplicações web através de componentes, tal como é feito em sistemas desktop: o programador deveria poder ter uma IDE visual para, via drag and drop, montar a tela. Essa especificação define quais são os componentes, como eles podem ser ligados, arrumados na tela e a semântica de sessão, configuração, etc. Enfim, ela é grande. Talvez por esse motivo, ela é uma expansão de algo anterior, a JSR 245 (JSPs) e a JSR 127 (JSF 1.1). Utilíssima para as telas de cadastro porque define como fazer univocamente as coisas na web. Em outras palavras, é assim que se constrói interfaces web para Java. Essa é parte do Java EE 5, definida pela JSR Umbrella 244.
269: Pluggable Annotation Processing API - Essa a osmose não me atingiu e só fiquei sabendo dela pelo artigo do Danny Coward sobre novas features do Mustang. Serve para trabalhar com anotações via parsing no código-fonte do sistema. Por exemplo, quem vai criar um plugin para editores de código pode ser beneficiar muito dela. Quem conhece a ferramenta Apt (Annotation Processing Tool) do Java Tiger pode considerar essa JSR com a mesma coisa, mas agora com uma API e um comportamento mais transparente e extensível. Para as telas de cadastro, considero essa API uma coisa fundamental para o sistema de configuração baseada em histórico e plugin de edição do Merlin. São relacionadas as JSR 175 (anotações) e 14 (genéricos).
296: Swing Application Framework - Assim como a web ganhou servlets controladores e um conjunto de informações de deployment padronizadas (os web-descriptors), o Swing também vai ganhar um padrão para suas actions, tratamento de sessão, gerenciamento de preferências e outras coisas. É essa a JSR responsável por isso. Para as telas de cadastro, tudo de bom: poderemos (talvez) ter um consenso em como fazer várias coisas, desde políticas de gerenciamento de objetos em memória (e o vínculo deles com os controles de tela - um PresentationModel, por exemplo, só ganharia com isso) até recursos i18n.
223: Scripting for the Java Platform - Quem já usa o BeanShell (JSR 274) sabe a mão na roda que ele pode ser. Embora o Merlin já suporte ele, com o advento dessa JSR teoricamente Java poderá suportar qualquer linguagem de scripting. Por padrão o Java 6 virá com a implementação Mozilla Rhino, o que indica que scripts JavaScript (e outros) poderão interagir com objetos Java dentro da aplicação, mesmo as desktop. Para as telas de cadastro, uma flexibilidade extrema, abrindo possibilidades semelhantes às oferecidas pelos programadores VBA.
222: Java Architecture for XML Binding (JAXB) 2.0 - Ela é um seguimento da antiga JSR 31 (Java XML Data Binding) e a idéia dela é permitir o trabalho (criação, uso e manipulação) sobre arquivos XML de forma transparente. Ao usá-la, você sua impressão é que está trabalhando com objetos Java (Javabeans) que, ao final da sessão de trabalho, serão persistidos em arquivos XML. Muito rápida se comparada à Serialização Java. Para as telas de cadastro, considero útil para persistência de estados intermediários de sessões de usuário ou preferências (claro, eu sei que temos a API prefs para isso e agora também a JSR 296 que promete bastante) É esperar para ver.
224: Java API for XML-Based Web Services (JAX-WS) 2.0 - E aqui a parte dos webservices. Com essa JSR, estamos convergindo esforços para acesso a webservices e a interação com eles. Atuando em sincronia com a JSR 222 (JAXB) e com os padrões SOAP 1.2, WSDL 1.2, essa JSR promete facilidades no desenvolvimento e evolução de serviços para web. Assim, recursos como a abstração de mapeamento de objetos recebidos via JAX-RPC para objetos Java e vice-versa, podem atuar em conjunto com features de compilação on demand de classes e recursos de engenharia de bytecodes (BCEL, ASM, etc.). Na prática, vejo um futuro como uma aplicação Java conectando-se em um webservice (feito em .NET, por exemplo) e gerando stubs e classes em tempo de execução e com elas inicializando os dados e exibindo-os na IHC do usuário. Um mundo com conectividade total. Para as telas de cadastro, dou a dica: Um sistema baseado no Merlin pode conectar-se em um webservice qualquer (feito em .NET, de novo!) para obter dados. O JAX RPC traz esses dados e gera das classes Java em tempo de execução junto com o trabalho de mapeamento do JAXB. Essas classes vão para a árvore de classloaders do sistema. O Merlin lê essas classes e gera a tela de cadastro para elas, já inicializando os dados recebidos. O usuário pode, então editar esses dados. Dados alterados, o sistema faz o caminho inverso, sendo que no fim do trajeto um outro webservice recebe os dados (automaticamente mapeados) e persiste em uma base qualquer. Legal, né? Também acho :-)
295: Beans Binding - Essa é ótima. Pelo menos é o que eu imagino que os desenvolvedores desktop deveriam pensar. A idéia é ligar controles de tela e objetos de dado astravés de uma coisa como a Expression Language (EL) usada pelos programadores JSF. Não está no request da especificação, mas acho que também deveria estar disponível um mecanismo de validação e invocação de ações para os controles. No Merlin, eu fiz um esquema de Agentes para isso, como na Eiffel. Essa JSR é crítica ao meu ver, pois centraliza inúmeros pontos que possuem tratamentos a la vonte pelos programadores: desde patterns como o famigerado PresentationModel até códigos ad hoc sobre listeners como o PropertyChangeListener. Para as telas de cadastro? Um ponto único de trabalho para gerenciar a ligação entre os controles de tela e os objetos do sistema.
Bom, como disse, são JSR às pampas. E não estão aqui todas as que considero ligadas às telas de cadastro. Apenas listei as que vieram à cabeça no momento. A dica que deixo é: Mantenham-se atentos às JSRs.
0 comentários:
Postar um comentário