06 – Mudanças nas certificações Java Confira as alterações e as novidades [ Everton Coimbra de Araújo e Scheila Giongo ]
12 – EJB 3.1 versus CDI Java a v a J
CDI pode substituir os tradicionalmente mal afamados EJBs? [ Adam Victor Nazareth Brandizzi ]
20 – Por dentro do JavaFX 2 Java
Java, Tutorial
Java
Automatizando o versionamento de projetos com SVN, Maven e Nexus [ Rodrigo Branas ]
Cluster de servidores, balanceamento de carga e tuning [ Pablo Bruno de Moura Nóbrega ]
54 – Paradigmas da Mobilidade Mobile
e r a w ft o S e d
h n e g n E
34 – Mantenha suas versões em dia
42 – Alta disponibilidade com GlassFish
s a ic t á r P s a o B
a ri a
Uma nova plataforma para desenvolvimento de aplicações ricas para Web [ Luiz Carlos Querino Filho ]
Um estudo sobre as abordagens web, nativa e híbrida [ Pedro E. Cunha Brigatto ]
Olá, eu sou oDevMan! Desta página em diante, eu estarei lhe ajudando a compreender com ainda mais facilidade o conteúdo desta edição. Será um prazer contar com sua companhia! Confira abaixo o que teremos nesta revista:
66 – Testes no Scrum Engenharia de Software
2
Processo de Teste de Software adaptado ao Scrum [ Juvenal Feitosa, Gustavo Alves e Felipe Furtado ]
Brinde na web desta edição • 2 vídeo-aulassobre o padrão Template Method.
Vídeos
Para visualizar acesse o link: http://www.devmedia.com.br/articles/listcomp.asp?keyword=jm105&codigobanca=ja va fx 2
Gostou das vídeo aulas? O portal www.devmedia.com.brpossui mais de2 mil vídeo aulase dezenas de cursos online sobre desenvolvimento de software!
Agora você pode comprar as vídeo aulas que preferir e fazer sua própria combinação de vídeos! Saiba mais www.devmedia.com.br/creditos em
D
ê
s
u
e
Dê seu feedback sobre esta edição!
Feedback
A Java Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! s
o
b
r
oãçi
de
e
e
s
at
Dê seu voto sobre esta edição, artigo por artigo, através do link: www.devmedia.com.br/javamagazine/feedback Para votar, você vai precisar do código de banca desta edição, que é:javafx2
Carta ao Leitor Ano IX • Edição 105 • 2012 • ISSN 1676-8361
Produção Jornalista Responsável Kaline Dolabella - JP24185
Distribuição FC Comercial e Distribuidora S.A Rua Teodoro da Silva, 907, Grajaú - RJ CEP 20563-900, (21) 3879-7766 - (21) 2577-6362
Atendimento ao leitor A DevMedia possui uma Central de Atendimento on-line, onde você pode tirar suas dúvidas sobre serviços, enviar críticas e sugestões e falar com um de nossos atendentes. Através da nossa central também é possível alterar dados cadastrais, consultar o status de assinaturas e conferir a data de envio de suas revistas. Acesse www.devmedia.com.br/central, ou se preferir entre em contato conosco através do telefone 21 3382-5038.
Edições anteriores Adquira as edições anteriores da revista Java Magazine ou de qualquer outra publicação do Grupo DevMedia de forma prática e segura, em www.devmedia.com.br/anteriores.
Anúncios – Anunciando nas publicações e nos sites do Grupo DevMedia, você divulga sua marca ou produto para mais de 100 mil desenvolvedores de todo o Brasil, em mais de 200 cidades. Solicite nossos Media Kits, com detalhes sobre preços e formatos de anúncios. Reprints Editoriais – Se foi publicado na Java Magazine um artigo que possa alavancar as suas vendas, multiplique essa oportunidade! Solicite a reimpressão da matéria junto com a capa da edição em que saiu, e distribua esse reprint personalizado entre seus clientes. Encarte de CDs – Faça como nossos maiores anunciantes. Encarte um CD com uma amostra de seus produtos na Java Magazine e atinja um público segmentado e formador de opinião. Java, o logotipo da xícara de café Java e todas as marcas e logotipos baseados em/ ou referentes a Java são marcas comerciais ou marcas registradas da Sun Microsystems, Inc. nos Estados Unidos e em outros países.
Fale com o Editor!
É muito importante para a equipe saber oartigo na revista ou no site Java Magazine, que você estáachando da revista:que tipo entre em contato com o editor, informando de artigo você gostaria de ler,que artigo você o título e mini-resumo do tema que você mais e qual artigo vocêemmenos gostou. Fiquegostou a vontade para entrar contato comgostaria de publicar: os editores e dar a sua sugestão! Eduardo Spínola - Editor da Revista Se você estiver interessado em publicar um [email protected]
D
esde a sua primeira versão, o JavaFX, até então, não chegou a se firmar como uma das preferências dos desenvolvedores Java. Apesar de ter recebido bons investimentos durante o período de seu lançamento, por diversas características e decisões de projeto, a nova plataforma Java acabou não agradando como se esperava. Um dos motivos para isso se chamava JavaFX Script. Esta nova linguagem, no entanto, não acabou, mas agora, para criar aplicações RIA com JavaFX, utilizar nossosmais sólidos conhecimentos anos de experiência com a tradicional e forte APIpodemos Java. Assim, não temos a “barreira inicial”, de facilitando sua adoção e ajudando a alavancar mais uma importante e promissora plataforma Java. Dessa forma, Por dentro do JavaFX 2 apresentará esta renovada tecnologia, voltada à implementação de aplicações cliente ricas para a Internet em múltiplas plataformas. Para isso, uma introdução à tecnologia, seu histórico e principais recursos serão apresentados, junto a exemplos práticos onde serão demonstradas algumas das suas funcionalidades. Mudanças nas certificações Java retrata as mudanças em relação às certificações Java da Oracle. As novas siglas, alterações em conteúdos aplicados, cursos obrigatórios, de preparação, realizados antes de algumas certificações, e as categorias das certificações envolvendo as plataformas Java SE, Java EE e Java ME também serão abordadas. Mudando um pouco de assunto, o desenvolvedor Java EE pode se sentir confuso diante da versão 6 desta plataforma porque algumas tecnologias parecem se sobrepor – notadamente EJB e CDI. Sendo EJB uma tecnologia tradicionalmente complicada e improdutiva, o programador se pergunta se é possível substituir EJB por CDI, e como fazê-lo. EJB 3.1 versus CDI explorará as duas possibilidades: trocar EJB por CDI ou usar CDI com EJB. Veremos que ambas são viáveis, e que a segunda opção pode ser vantajosa. Em Mantenha suas versões em diavamos aprender como criar um processo de versionamento e como extrair o melhor das ferramentas SVN, Maven e Nexus para automatizar o lançamento de novas versões com segurança e estabilidade. A adoção de um processo de versionamento automatizado ajuda a elevar o nível de maturidade e organização da empresa, garantindo um controle rígido sobre as modificações realizadas pela equipe de desenvolvimento. No artigo Alta disponibilidade com GlassFish, mostraremos como configurar um cluster com balanceamento de carga no GlassFish para alcançar alta disponibilidade. Em seguida, veremos como efetuar tuning no desenvolvimento de sistemas e nas configurações do servidor para conseguirmos ganho de performance. O artigo Paradigmas da Mobilidadevisa proporcionar uma leitura objetiva sobre os paradigmas nativo, híbrido e web, adotados na codificação de soluções móveis. Através de uma análise de aspectos como consistência e desempenho de plataformas e tecnologias já estabelecidas, bem como de outras mais recentes e muito bem cotadas no cenário de mobilidade, além de aspectos como a disponibilidade de capitais financeiro e humano, convidamos o leitor para uma reflexão sobre a aplicabilidade de cada uma destas propostas. Diante do crescimento das Metodologias Ágeis, em especial, do framework Scrum, diversos desafios surgem para as atividades de testes nestes ambientes. Pensando nisso, no artigo Testes no Scrum, os autores levantaram estes desafios e propuseram uma adaptação do processo de testes fundamental às atividades do Scrum. Aproveitem ao máximo esta edição, e boa leitura!
Assine agora e tenha acesso a todo o conteúdo da DevMedia: www.devmedia.com.br/mvp
a v a J o ã ç e S
NESTA SEÇÃO VOCÊ ENCONTRA ARTIGOS INTERMEDIÁRIOS E AVANÇADOS SOBRE JAVA
Mudanças nas certificações Java Cursos obrigatórios, nomenclaturas e conteúdos aplicados sofreram modificações nas certificações Java geridas pela Oracle
S
er um profissional certificado Java é ter um diferencial na carreira, pois a certificação confirma a aptidão para a tecnologia. Devido à sua real importância, a certificação é um assunto muito discutido entre desenvolvedores, pois depende de quem faz e para que objetivo a obtém. A abordagem aqui apresentada busca responder as principais dúvidas de um programador, em relação a uma certificação Java. É importante ter ciência que os exames de certificação, para os fabricantes que os mantém, são documentos que formalizam a competên cia de profissionais para atuarem no mercado, com destreza e conhecimento, para o produto, tecnologia ou metodologia ao qual o certificado se aplica. Esta situação pode ser comprovada quando se verifica, dentre os pré-requisitos das vagas ofertadas, a necessidade de certificações e não mais apenas a experiência profissional comprovada. A certificação pode ser vista, demaneira análoga, como um atestado de competência, um diferencial na carreira profissional, mas apenas obter a certificação, sem experiência, não é o suficiente. A certificação pode também ser vista como um meio para o profissional testar e adquirir conhecimento, pois o processo de tornar-se certificado, além de desafiar a profundidade e a amplitude de suas habilidades técnicas, é uma maneira de ganhar em termos de aprendizado e crescimento como profissional de TI. Pode-se assumir quea preparação não só a obtenção de umaé certificação, mas também para obtê-la, um ponto importante e positivo, pois é uma maneira organizada para se conhecer melhor o Java. Deste modo, é importante que o profissional que julga a certificação como algo não tão relevante tenha ciência de que existem empresas (de todos os portes) que se preocupam em ter em sua equipe profissionais certificados.
6 Java Magazine
•
Edição 105
Resumo DevMan De que se trata o artigo: O artigo apresenta as mudanças em relação às certificações Java da Oracle. As novas siglas,mudanças em conteúdos aplicados, cursos obrigatórios, de preparação, realizados antes de algumas certifica ções, e as categorias das certificações envolvendo as plataformas Java SE, Java EE e Java ME também serão abordadas.
Em que situação o tema é útil: Para desenvolvedores que desejam informar-se sobre as mudançasnas certificações Java e conhecer os assuntos e objetivos de cada exame, bem como as habilidades fundamentais que são necessárias em cada prova.
Mudanças nas certificações Java: A tecnologia Java oferece, por meio da Oracle, uma série de certifica ções de diversas categorias e perfis. Com a aquisição da Sun, algumas modificações ocorreram em relação a estas certificações. Um exemplo é a troca de nomenclatura, que agora é constituída com a marca da Oracle.lém A dessas mudanças, outras são exemplificadas no artigo, que contextualiza, em sua introdução, a importância de ser um profissional certificado. As certificações Java abrangem três áreas: Java SE, Java EE e Java ME, e dentro dessas áreas são aplicadas quatro categorias de provas: Associate, Professional, Master e Expert. Nessas categorias existem várias certificações embutidas, as quais serão abordadas ao longo do artigo.
De acordo com Kathy Sierra (uma das desenvolvedoras do exame), passar no exame provará três itens importantes para o empregador atual ou futuro: “que você sabe das coisas; que sabe como estudar e se preparar para um teste desafiador; e acima de tudo que conhece a tecnologia e está de acordo com os objetivos cobrados para tal exame. Se um empregador tiver que optar entre um candidato que passou no exame e outro que não tenha passado, ele saberá que o programador certificado não demorará no aprendizado”.
Uma pesquisa realizada pela Oracle afirma que candidatos que conquistam a certificação conquistam também um diferencial em suas remunerações, recebendo um retorno sólido de seu investimento. Em uma base global, profissionais que são certificados ganham 13,7% a mais do que aqueles que não são certificados. Levando em consideração todas as regiões do mundo, indivíduos certificados ganham significativamente mais do que aqueles que não são certificados. Possuir uma certificação contempla questões como maior satisfação no trabalho, um dos quesitos que exercem influência na carreira profissional. Além de atingir uma remuneração mais elevada, como indicado na pesquisa, aqueles que se tornam Oracle Certified têm mais confiança e credibilidade, são mais produtivos e possuem maiores chances de empregabilidade, fatores adicionais que elevam a satisfação. Com a compra da Sun pela Oracle, foram anunciadas algumas modificações para as certificações, mudanças essas abordadas ao longo do artigo. No entanto, é importante ressaltar que mesmo após as alterações nas certificações Java/Oracle, as certificações da Sun continuam a ser reconhecidas.
Nesta plataforma, a primeira categoria éconhecida como Associate, ou OCA – Oracle Certified Associate. Esta categoria é obrigatória para o profissional que deseja avançar para os demais níveis. Uma das mudanças realizadas foi em relação à nomenclatura, que anteriormente possuía a marca da Sun em sua assinatura, sendo conhecida como Sun Certified Java Associate (SCJA). O objetivo que abrange o nível OCA é garantir que o candidato esteja equipado com as competências fundamentais, como os conceitos básicos sobre OO e conhecimentos gerais sobre tecnologias Java. Nessa categoria está incluso a certificação Oracle Certified Associate (OCA), Java SE 5/SE 6, que possui o código de exame 1Z0-850, anteriormente conhecida como Sun Certified Java Associate (SCJA) SE 5/SE 6. Está incluso também a certificação beta Oracle Certified Associate, Java SE 7 Programmer I (exame 1Z0-803), para a versão 7 do Java. Uma novidade é que a certificação OCJA 7 é obrigatória , ou seja, pré-requisito para realizar a certificação OCJP 7, descrita no nível Professional no decorrer do artigo. Esta obrigatoriedade se justifica pelas mudanças que ocorreram no seu conteúdo, que foi totalmente reformulado, não possuindo os mesmos objetivos da antiga OCJA. O conteúdo abordado na OCJA implicava em um Novas siglas e provas “conhecimento conceitual”, com questões sobre fundamentos, moUma das mudanças nas certificações Java está relacionada às delagem UML e orientação a objetos, bem como uma visão geral nomenclaturas, que agora levam a marca Oracle em seus nomes. sobre a plataforma Java. Agora o conteúdo é muito mais prático, As certificações Oracle abrangem três plataformas de desenvolenvolvendoquestões que antes eram aplicadas apenas na OCP. Os vimento: Java Platform, Standard Edition (Java SE); Java Platform, novos tópicos do exame cobrados na certificação OCJA são: Enterprise Edition (Java EE); e Java Platform, Micro Edition (Java • Noções básicas sobre Java; ME), detalhadas em seções específicas neste artigo. • Trabalhando com tipos de dados Java; Dentro dessas três plataformas são aplicadas quatro categorias • Criar e manipular Strings; para as certificações, com o objetivo de demonstrar o grau de co• Criando e usando Arrays; nhecimento e habilidade de cada profissional, que são: Associado, • Usando Loop; Profissional, Master e Especialista. • Trabalhando com Métodos e encapsulamento; Outra mudança, decorrente após a Oracle se tornar detentora • Trabalhando com Herança; dos direitos sobre o Java, foi a inclusão de mais quatro provas de • Tratamento de exceções. certificação, somando agora um total de doze. Com essa mudança de conteúdo na certificação Java SE 7, se Java SE exige um conhecimento mais elevado devido aos novos conceitos As certificações para a plataforma Java SE buscam qualificar cobrados. Contudo,o profissional só tem a ganhar, pois acrescenta profissionais que dominem a construção de aplicações para o maior valor e credibilidade para aqueles que desejam obter a cerambiente corporativo. Java SE contém todo o ambiente necestificação em Java SE 7, e demonstra que o profissional é proficiente nos mais recentes avanços em programação Java. sário para a criação e execução de aplicações Java, sendo a base para desenvolver qualquer tipo de sistema, seja ela móvel, web Cabe destacar que o profissional que possui a certificação OCJP 5 ou desktop. Confira na Figura 1 as certificações disponíveis para ou OCJP 6 não necessita realizar a prova OCJA, pois seu certificado essa plataforma. continua a ser reconhecido.
Figura 1. Certificações Java SE
A segundaprofissional categoria da plataforma Java SE compreende habilidade voltada para conhecimentos técnicosa necessários para gerir e desenvolver aplicações, bases de dados ou middlewares em ambientes corporativos. Essa categoria é descrita como Professional, OCP – Oracle Certified Programmer, cuja nomenclatura era anteriormente conhecida como Sun Certified Java Programmer (SCJP). Ao alcançar a certificação OCP , evidencia-se que o programador entende a sintaxe e as estruturas básicas da linguagem de Edição 105 Java Magazine •
7
Mudanças nas certificações Java
programação Java, sendo capaz de criar um aplicativo em Java que seja executado em servidores e sistemas desktop. A categoria OCPé composta pelas seguintes certificações: Oracle Certified Professional (OCP), Java SE 5 Programmer (exame 1Z0853), anteriormente conhecida como Sun Certified Java Programmer (SCJP SE 5); Oracle Certified Professional (OCP), Java SE 6 Programmer (exame 1Z0-851), conhecida anteriormente como Sun Certified Java Programmer (SCJP SE 6); e Oracle Certified Professional, Java SE 7 Programmer II (exame 1Z1-804). A prova Oracle Certified Professional, Java SE 7 Programmer II, está em fase beta. Os tópicos do exame dessa certificação ainda não foram apresentados, pois parte de seu conteúdo foi para a OCJA 7. O caminho para atingir a OCJP 7 é descrito na Figura 2.
baseados na web e aplicações corporativas. A plataforma Java EE inclui muitos componentes do Java SE e incide em um conjunto de protocolos, servidores e APIs que fornecem a funcionalidade para desenvolver aplicativos multicamadas com base na web. Confira na Figura 3 as certificações disponíveis para Java EE.
Figura 3. Certificações Java EE
Figura 2. Caminho para a certificação Java 7
Caso o profissional já possua uma certificação profissional (SCJP ou OCPJP, qualquer edição) e deseja obter a certificação OCPJP SE 7, basta realizar o exame chamado de Upgrade, 1Z0-805. O exame é formado por questões sobre os assuntos que mudaram de uma versão para outra. Além desse exemplificado, há exames de Upgrade para outras certificações. Deste modo é necessário estar atento para fazê-los quando disponíveis. A terceira categoria da plataforma Java SE é o nível Master, destinado para desenvolvedores que têm amplo conhecimento e que estejam interessados em demonstrar proficiência avançada na linguagem. Esta categoria é conhecida como OCM – Oracle Certified Master, anteriormente chamada de Sun Certified Java Developer (SCJD). Dentro desse nível é aplicada a certificação Oracle Certified Master (OCM), Java SE 6 Developer. Uma das mudanças que ocorreram nessa certificação é que para realizá-la é necessário que o profissional faça um dos cursos obrigatórios oferecidos pela Oracle (mais informações sobre esses cursos são descritas no sub tópico “Cursos preparatórios”). Java EE
As certificações voltadas para o ambiente Java EE são destinadas a profissionais que possuem conhecimento em aplicativos
8 Java Magazine
•
Edição 105
Algumas das certificações aplicadas para essa plataforma possuem como pré-requisito outras certificações, como é o caso da certificação Oracle Certified Professional, Java EE 5 Web Component Developer, destinada a profissionais que possuem conhecimento especializado em desenvolvimento de aplicações para web services e conteúdo dinâmico para a web usando JavaServer Pages e Servlets. Para realizar essa certificação é pré-requisito que o profissional tenha sido aprovado em uma das seguintes certificações: Oracle Certified Professional, Java SE 5 Programmer (de código 1Z0-853), ou Oracle Certified Professional, Java SE 6 Programmer (de código 1Z0-851). A certificação Oracle Certified Professional, Java EE 5 Web Component Developer também sofreu alteração em sua nomenclatura, sendo antes conhecida como Sun Certified Web Component Developer (SCWCD) EE 5. A Oracle Certified Professional, Java EE 5 Business Component Developer, anteriormente Sun Certified Business Component Developer (SCBCD) EE 5, é outra certificação aplicada na área de conhecimento Java EE. Ela testa as competências de programadores com experiência em projeto, desenvolvimento, teste, implantação e integração de aplicações utilizando a tecnologia EJB (Enterprise JavaBeans). O exame se aplica a profissionais que desenvolvem aplicativos de negócios que utilizam componentes do lado do servidor. O exame que verifica a habilidade de um programador em criar serviços Web para aplicações que utilizam componentes da tecnologia Java é o Oracle Certified Professional, Java EE 5 Web Services Developer (OCPJWSD), anteriormente conhecido como Sun Certified Developer for Java Web Services 5 (SCDJWS). Esta certificação também está para disponível a versão Java EE 6, com a nomenclatura alterada Oraclepara Certified Professional, Java EE 6 Web Services Developer. Na categoriaMaster da área de conhecimento Java EE, atualmente se tem apenas uma certificação, a Oracle Certified Master, Java EE 5 Enterprise Architect, anteriormente conhecida como Sun Certified Enterprise Architect (SCEA) EE 5. Esse exame destina-se a arquitetos corporativos, responsáveis pela arquitetura e design de aplicativos. Para realização do mesmo, é necessário fazer um
dos cursos obrigatórios da Oracle (esse assunto será abordado com maior ênfase no sub tópico “Cursos preparatórios”). Para profissionais que desejam obter um diferencial na carreira em áreas mais específicas, existem as certificações sobre: JSF, anteriormente conhecida como Sun Certified Developer for the JSF for the Java EE 6 Platform, e atualmente modificada para Oracle Certified Professional, Java Platform, Enterprise Edition 6 JavaServer Faces Developer; EJB, anteriormente chamada de Sun Certified EJB Developer for the Java EE 6 Platform, e atualmente Oracle Certified Professional, Java Platform, Enterprise Edition 6 Enterprise JavaBeans; e a certificação referente à JPA, conhecida como Sun Certified JPA Developer for the Java EE 6 Platform, que ganhou o nome de Oracle Certified Professional, Java Platform, Enterprise Edition 6 Java Persistence API. Uma novidade da Oracle é o lançamento da certificação Oracle Certified Expert, Java Platform, EE 6 Web Component Developer, que substitui a de código 1Z0-894 (Oracle Certified Expert, Java Platform, Enterprise Edition 6 JavaServer Pages and Servlet Developer). Essa certificação é destinada a desenvolvedores experientes em aplicativos Java, com conhecimentos e habilidades para construir rapidamente aplicações web adequadas a qualquer servidor de aplicação Java EE 6, utilizando JSP e servlet. Não há mudanças em relação ao conteúdo aplicado no exame 1Z0-894, apenas em seu código, que agora passa a ser 1Z0-899. Além da certificação OCE acima descrita, foram disponibilizadas mais três novas certificações para Java EE, a saber: Oracle Certified Expert, Java Platform, Enterprise Edition 6 Enterprise JavaBeans Developer (OCEJEJBD); Oracle Certified Expert, Java Platform, Enterprise Edition 6 Java Persistence API Developer (OCEJJPAD); e a Oracle Certified Expert, Java Platform, Enterprise Edition 6 Web Services Developer (OCEJWSD).
de certificação. Atualmente entraram para essa lista de novas exigências duas certificações: 1. Oracle Certified Master, Java SE 6 Developer (Certificação de Desenvolvedor Java); 2. Oracle Certified Expert, Java EE 5 Enterprise Architect (Certificação de Arquiteto Java).
Figura 5. Caminho para a certificação na plataforma Java ME
Java ME
Na plataforma Java ME, o objetivo é certificar profissionais que desenvolvem aplicações utilizando Java Platform, Micro Edition, destinada a dispositivos móveis, PDAs, aparelhos celulares, dentre outros. Veja na Figura 4 a certificação disponível para Java ME.
Figura 4. Certificação Java ME
A Oracle oferece para certificação Oracle Certified Professional, Javaesse MEambiente 1 MobileaApplication Developer, anteriormente conhecida como Sun Certified Mobile Application Developer (SCMAD). Observe naFigura 5 o caminho a percorrer para atingir esta certificação. Cursos preparatórios
Uma novidade que nãoexistia na metodologia utilizada pela Sun é a realização de cursos obrigatórios antes de fazer uma prova Edição 105 Java Magazine •
9
Mudanças nas certificações Java
Para o candidato que deseja realizar qualquer uma dessas duas Everton Coimbra de Araújo certificações, é necessário fazer pelo menos um dos cursos Oracle [email protected] Desde 1987 atua na área de treinamento e desenvolvimento. É mestre listados abaixo: em Ciência da Computação, e professor efetivo da UTFPR, Campus Me• Linguagem Java (Java Programming Language, Java SE 6); dianeira. Tem se dedicado às disciplinas relacionadas ao desenvolvimento de • Fundamentos de Java (Fundamentals of the Java Programming aplicações web e na persistência de objetos, focando seus estudos e pesquisas Language, Java SE 6); na plataforma Java e .NET. É autor da Visual Books, com oito livros já publicados. • Desenvolvimento de aplicações (Developing Applications with the Java SE 6 Platform); • Análise orientada a objetos e Design usando UML (ObjectScheila Giongo Oriented Analysis and Design Using UML); [email protected] • Tuning de performance em Java SE (Java SE Performance Tuning). Os cursos preparatórios são realizados de maneira presencial ou on-line nos centros de treinamento oficiais da Oracle.
Conclusão Este artigo apresentou as mudanças e novidades referentes às certificações Java, que envolvem: mudanças nas nomenclaturas, novos conteúdos abordados, novas provas e os cursos obrigatórios, de preparação, realizados antes de algumas certificações. Além disso, foram apresentadas as categorias que abrangem as plataformas Java SE, Java EE e Java ME, e as habilidades exigidas aos profissionais, decorrentes de cada área. A importância de ser um profissional certificado traz somente vantagens no mercado de trabalho, ficando a cargo do profissional que tiver interesse em testar seus conhecimentos e/ou conquistar um diferencial em sua carreira, decidir qual a melhor certificação para seus objetivos.
Graduada em Tecnologia em Análise e Desenvolvimento de Sistemas pela Universidade do Oeste de Santa Catarina (UNOESC - Campus Xanxerê). Possui especialização em projeto e desenvolvimento de sistemas baseados em objetos para ambiente internet, na Universidade Tecnológica Federal do Paraná (UTFPR - Campus Medianeira). Trabalha como desenvolvedora web na Viasoft, empresa especializada na produção de softwares de gestão empresarial.
NESTA SEÇÃO VOCÊ ENCONTRA ARTIGOS INTERMEDIÁRIOS E AVANÇADOS SOBRE JAVA
EJB 3.1 versus CDI CDI pode substituir os tradicionalmente mal afamados EJBs?
E
nterprise JavaBeans (EJBs) sempre foram componentes supervalorizados pelas especificações Java EE. Entretanto, sua adoção foi menor do que o esperado de uma tecnologia oficial tão central. A principal razão é a imensa complexidade de desenvolvimento. EJBs exigiam a criação de várias interfaces, frequentemente redundantes; o empacotamento de componentes em intricadas estruturas de pacotes; o uso de servidores de aplicações complexos e pesados etc. Todas estas desvantagens elevavam muitoo custo inicial de se usar EJBs, de modo que sua adoção se manteve mais ou menos restrita a grandes organizações. Como alternativa à complexidade, surgiram frameworks leves, como Spring, que proviam várias das vantagens de EJBs com muito menos recursos e complicações. As especificações da plataforma corporativa de Java, porém, evoluíram para tornar EJBs mais palatáveis. A API Java EE 6 foi o mais recente e significativo passo nesta direção, com a especificação EJB 3.1. Esta versão dispensa muito da complexidade tradicionalmente associada à arquitetura, provendo inclusive um pequeno mas significativo subconjunto da especificação maior, chamado EJB Lite. Por outro lado, Java EE 6 também provê um novo modelo de gerenciamento de objetos chamado de Contexts and Dependency Injection (CDI). Esta especificação (redigida na JSR 299) acrescenta a Java EE um sistema de injeção de dependências e o conceito de escopos, além de várias funcionalidades como eventos, interceptadores, entre outros. Muito de CDI foiinspirado em alternativas à EJB, como Spring, Guice e Seam. Muitas funcionalidades que eram formalmente suportadas apenas por EJBs podem, agora, ser utilizadas através de CDI. Ademais, CDI é mais simples que EJBs – inclusive a versão 3.1 – e, semanticamente, poderoso e flexível. A sobreposição édemais funcionalidades das duas tecnologias levantou suspeitas e gerou boatos sobre o futuro de Java EE e, especialmente, dos EJBs. Por exemplo, vários desenvolvedores já cogitam substituir completamente EJBs por CDI. É bem verdade que a JSR 299 especifica como EJBs devem ser relacionados com a nova arquitetura de injeção de dependências, e a documentação de Weld (a implementação de referência de CDI) recomenda
12 Java Magazine
•
Edição 105
Resumo DevMan De que se trata o artigo: Duas novas especificações de Java EE: EJB 3.1 e CDI. Estas tecnologias possuem, por vezes, funcionalidades que se sobrepõem, e parece possível substituir EJBs por CDI . É realmente possível? Como? É vantajoso? Veremos respostas para estas perguntas neste artigo.
Em que situação o tema é útil: Tanto CDI quanto EJB 3.1 são especificações oficiais JavaEE, de modo que é muito positivo conhecê-las. Além disto, e ao contrário de várias especificações, são tecnologias muito simples, práticas, úteis e poderosas. Assim, é conveniente que o desenvolvedor as conheça para saber quando é positivo utilizá-las, como integrá-las ou mesmo como substituir uma por outra.
EJB 3.1 versus CDI: O desenvolvedor Java EE pode sesentir confuso diante da versão 6 da plataforma porque algumas tecnologias parecem se sobrepor notada– mente EJB e CDI. Sendo EJB uma tecnologia tradicionalmente complicada e improdutiva, o programador se pergunta se é possível substituir EJB por CDI, e como fazê-lo. Este artigo explorará as duas possibilidades: trocar EJB por CDI ou usar CDI com EJB. Veremos que ambas são viáveis, e que a segunda opção pode ser vantajosa.
o uso de EJBs “quando se precisa dos serviços que eles provêm.”. Entretanto, muitos se perguntam: por que usar EJBs quando estes mesmos serviços podem ser usados através de CDI, só que de forma muito mais simples? Aliás, pode CDI realmente fornecer todas as funcionalidades providas por EJBs? É o que veremos neste artigo.
Uma breve história dos EJBs O conceito de EJB surgiu no final anos 90 eera início da década passada. O propósito principal dados arquitetura prover um meio padronizado de se desenvolver a lógica de negócio de uma aplicação, em oposição à lógica da interface com o usuário. Com EJBs, teoricamente seria possível executar toda a lógica de uma aplicação em um ou mais servidores, utilizando qualquer tipo de interface. Assim, a lógica da aplicação – validação, processamento de dados, persistência etc. – rodaria no servidor, e interfaces dos mais variados tipos – applets, programas em Swing, aplicações
web etc. – apenas invocaria os métodos da aplicação. Os diversos EJBs seriam utilizáveis da mesma maneira, independentemente de estarem no mesmo servidor ou não – isto é, seriam distribuídos de maneira transparente. A Figura 1 mostra um esquema do que se propunha.
especiais (chamados frequentemente de “ejb-jars” porque seu nome deve terminar com -ejb.jar) que precisavam de um descritor XML complicado chamado ejb-jar.xml. Se uma aplicação web fosse utilizar EJBs, era necessário adicioná-los em um ejb-jar e, paralelamente, adicionar o código web (JSPs e outras classes) em um arquivo WAR; posteriormente, os ejb-jars e o WAR deveriam ser empacotados em um outro arquivo, denominado EAR (de Enterprise ARchive).
Figura 1. Relação entre EJBs e interfaces.
Além disto, EJBs provinham uma série de funcionalidades que abstraíam detalhes de plataforma para o programador. Por exemplo, EJBs controlam transações e concorrência de threads automaticamente. Com EJBs, é possível responder a eventos, executar chamadas assíncronas e criar timers. Ademais, EJBs são acessíveis remotamente através de RMI e web services, podem exigir autenticação (por exemplo, via JAAS) e ser encontráveis através de JNDI.
Figura 2. Estrutura de uma aplicação corporativa mais simples e mais comum que a suportada por EJBs
Como consequência disto, EJBs passaram a ser menos populares. Para tornar o cenário ainda mais sombrio para este modelo de arquitetura, uma série de alternativas começou a ser desenvolvida. A principal, foi, provavelmente, o framework de injeção de dependências Spring. Lançado em 2002 por Rod Johnson, o framework Spring tinha como propósito claro criar uma arquitetura mais leve e produtiva que EJBs. O resultado foi bastante Os protestos contra a especificação positivo: Spring consolidou-se como uma das melhores e mais A plataforma obteve uma adoção respeitável por grandes compa- populares tecnologias para desenvolvimento em Java, popularinhias, inicialmente. Entretanto, a excessiva complexidade dosEJBs zou o conceito de injeção de dependências (que viria a ser ubíquo começou a gerar problemas. Desenvolvedores frequentemente sen- entre os javeiros) e foi pioneiro em utilizar menos XML e adotar tiam que havia pouco ganho real: se, por um lado, EJBs provinham pesadamente anotações. funcionalidades como transações e controle de concorrência, por A contrarreforma com EJB 3.x outro lado o grande número de interfaces requeridas, exceções a tratar, descritores XML complicados, etc. tornavam o processo Em resposta às evoluções dos framew orks concorrentes no de escrevê-los notavelmente complicado. mercado, os EJBs evoluíram também. Mudanças significativas Além disto, muitas das funcionalidades providas por EJBs já aconteceram em EJB 2.0 – como a adição de interfaces locais não eram necessárias em inúmeros projetos. aplicações corporativas eram basicamente aplicações webMuitas rodando em um único servidor – como mostra a representação na Figura 2 – e o foco em programação distribuída dos EJBs apenas tornavam o desenvolvimento destas aplicações mais complexo. Por exemplo, na versão srcinal da arquitetura a única maneira de se invocar um EJB era através de CORBA, o que tornava muito custoso o processo de chamar um método na própria máquina. Até mais recentemente, os EJBs deviam ser empacotados em arquivos JAR
para invocações de métodos mesmo contexto – mas a grande revolução veio com as versõesno3.x da arquitetura. Foi com EJB 3.0, por exemplo, que o descritor de implantação ejb-jar.xml deixou de ser obrigatório, tornando-se inclusive desnecessário em um grande número de situações. Em seu lugar, consistentemente adotaram-se anotações, recém-adicionadas, à época, em Java 5; agorabeans de sessão, interceptadores, timers, entre outros recursos passaram a ser configurados via anotações. Também se tornou possível escrever EJBs como POJOs anotados, Edição 105 Java Magazine •
13
EJB 3.1 versus CDI
dispensando a implementação de interfaces como SessionBean e EJBHome. Por sua vez, as interfaces locais tornaram-se desnecessárias – para invocar um método de um EJB localmente não era mais necessário criar uma interface separada. As anotações não foram adotadas apenas para configurar EJBs, mas também para permitir a injeção de recursos. Até EJB 2.x, a maneira padrão de se obter a referência a um EJB era através da classe InitialContext, que recuperava instâncias de recursos através de lookup. Um EJB na camada de serviço, por exemplo, que fosse utilizar um EJB da camada de persistência seria implementado de maneira semelhante à Listagem 1 . Em EJB 3.0, porém, é possível injetar uma instância de um EJB utilizando-se a anotação, como visto na Listagem 2 . Os dois exemplos de código mostram como a nova abordagem é bem mais prática, clara e sucinta.
arquivos WAR. E tanto os ejb-jars quanto os arquivos WAR, assim como quaisquer arquivos JAR necessários, deviam ser agrupados em um arquivo EAR, que tinha seu próprio descritor, chamado application.xml. A Figura 3 apresenta um diagrama que representa a estrutura de um hipotético arquivo EAR.
Listagem 1.Exemplo de recuperação (lookup) de dependências em EJB 2.x.
public class PessoaService { public List getPessoas() { try { InitialContext contexto = new InitialContext(); PessoaDAO pessoaDAO = (PessoaDAO) contexto.lookup(“ejb/PessoaDAO”); return pessoaDAO.getPessoas(); } catch (NamingException e) { e.printStackTrace(); return null; } } } Listagem 2.Exemplo de injeção de dependências em EJB 3.0.
public class PessoaService { @EJB private PessoaDAO pessoaDAO;
Figura 3. Estrutura de um arquivo EAR
Com EJB 3.1, é possível empacotar EJBs diretamente em um arquivo WAR. Os arquivos ejb-jar tornaram-se desnecessários e, com eles, o arquivo EAR, que tinha o propósito de associá-los à interface web. Assim, na nova especificação, uma aplicação web corporativa pode ter uma estrutura como a apresentada na Figura 4 . Como dissemos, o descritor ejb-jar.xml não é mais necessário, também.
public List getPessoas() { return pessoaDAO.getPessoas(); } }
Uma das maiores mudanças foi no modelo de persistência de EJB 3.0. Houve uma migração dos antigos beans de entidade (Entity Beans), altamente abstratos e complicados, para a Java Persistence API (JPA). A nova API para mapeamento objeto-relacional (ORM) é menos abstrata que os beans de entidade antigos (cuja especificação fora projetada para lidar com qualquer tipo de base de dados, não apenas as relacionais) e, por isto mesmo, é muito mais simples. Por isto, embora JPA não seja um componente
As interfaces de negócio também se tornaram desnecessárias, bastando anotar os beans com @Remote – embora ainda seja recomendável criá-las. Além disso, EJB 3.1permite criar EJBssingletons, que permitam compartilhamento de estado entre vários serviços, e chamada assíncrona de métodos através de anotações.
da especifaplicações icação de de EJBs (pode ser em contêineres de servlets, desktop ou utilizada mobile), ainda assim acabou tornando os beans de entidade obsoletos. EJB 3.1 deu sequência à simplificação. Uma das evoluções mais notáveis foi a dispensa do formato Enterprise Archive (EAR). Até EJB 3.0, uma aplicação corporativa devia ser empacotada em um complexo arquivo EAR. Os EJBs da aplicação vinham dentro de arquivos ejb-jar; as classes responsáveis pela interface web, assim como JSPs e outros recursos, eram empacotadas dentro de
a novidadedeque lite. Como o Entretanto, espírito simplificador EJBprovavelmente 3.1 é o conceitomelhor de EJBdemonstra toda tecnologia Java, EJBs são retroativamente compatíveis: uma aplicação implementada em, digamos, EJB 2.0, deve rodar em um servidor de aplicações que suporte EJB 3.1, ao menos com poucas alterações. Entretanto, o legado de versões anteriores pode tornar o desenvolvimento de novos servidores de aplicações realmente complicado, e os novos desenvolvedores Java EE têm geralmente pouco interesse em padrões antigos. Para reduzir o
14 Java Magazine
•
Edição 105
Figura 4. Arquivo WAR contendo EJBs
custo de implementar e compreender versões antigas do padrão, Java EE 6 apresenta o conceito de EJB lite, que é um subconjunto das especificações de EJB 3.1. Deste modo, um servidor de aplicações que implemente apenas EJB lite deve prover as seguintes funcionalidades: • Beans de sessão stateless, stateful e singletons; • EJBs com interface local e EJBs sem interface; • Interceptadores; • Gerenciamento de transações; • Recursos de segurança de EJBs, tanto declarativos quanto programáticos; e • Embeddable API – isto é, a API para execução de EJBs dentro da JVM do cliente, geralmente para testes unitários. A própria ideia de uma versão mais simples de EJB já seria suficiente para mostrar o comprometimento da especificação Java EE 6 com a simplificação do desenvolvimento corporativo em Java. De fato, EJB 3.1 (tanto a versãolite quanto a completa) é bem mais simples e prático que seus predecessores, e é possível que recupere ao menos boa parte do mercado que havia perdido para as soluções mais leves.
Entretanto, Java EE 6 trouxe muito mais que EJB 3.1. De fato, junto com a nova versão dos EJBs foi apresentada uma especificação que poderia muito bem ser concorrente do próprio EJB 3.1. Esta especificação é conhecida comoContexts and Dependency Injection – isto é, CDI.
Contexts and Dependency Injection De todas as novidades em Java EE 6, talvez não seja exagero afirmar que a mais revolucionária seja CDI. Esta nova especificação, definida na JSR-299, trouxe para o mundo dos padrões Java funcionalidades há muito populares em frameworks de terceiros, como injeção de dependência e ciclos de vida baseados em contexto. CDI se destacou, porém, por seu modelo de programação inesperadamente simples e, ainda assim, singularmente poderoso e flexível. Este novo modelo consegue, além do mais, manter compatibilidade retrógrada com padrões Java EE e, notadamente, não exige nem é centrado em EJBs . - CDI é um assunto amplo demais para ser abordado neste artigo, de modo que assumimos que o leitor já possua algum conhecimento sobre ele. Caso necessite estudá-lo, a Edição 84 da Java Magazine inicia uma série de artigos bastante instrutivos sobre o tema. Há um link para o início da série ao final deste artigo.
Edição 105 Java Magazine •
15
EJB 3.1 versus CDI
O que CDI oferece
Os desenvolvedores Java EE experientes não puderam deixar de notar a duplicação de algumas funcionalidades de EJB em CDI. Por exemplo, a injeção de dependências via @EJB agora pode ser feita com a anotação @Inject, que, não obstante, é muito mais poderosa: além de permitir injetar EJBs entre si, também é capaz de executar a injeção de dependências nos POJOs conhecidos como beans gerenciados. Em outras palavras, @Inject não só atende a todas as necessidades atendidas por @EJB, como também permite utilizar injeção de dependências em objetos que não sejam EJBs. Assim, se um programador almejava criar EJBs para poder executar injeção de dependências de acordo com os padrões, já não o precisa fazer em Java EE 6.
melhor alternativa para aplicações que tenham uma arquitetura semelhante à apresentada na Figura 2 , na qual toda a lógica é executada em um único servidor. Mesmo a comunicação entre serviços distribuídos é possível de ser feita, hoje em dia, através de web services, seja com SOAP ou REST. Neste contexto, um desenvolvedor pode se perguntar: há ainda alguma vantagem em utilizar EJBs? É possível abandoná-los completamente em favor de CDI? O que CDI não oferece
Esta é uma maneira muito mais flexível, intuitiva e prática de gerenciar o ciclo de vida de instâncias e, novamente, independem de EJB. Por outro lado, é possível colocar EJBs em qualquer um destes escopos. Ademais, assim como EJBs, é possível escrever interceptadores para os beans gerenciados de CDI. Os interceptadores de CDI são consideravelmente mais simples e flexíveis que os interceptadores de EJB. Caso os interceptadores não sejam exatamente o que o desenvolvedor deseja, CDI permite a criação de decoradores ,
A resposta para esta questão é mais complexa do que pode parecer à primeira vista. Apesar de todo o seu poder, CDI não provê várias funcionalidades dos EJBs, inclusive algumas muito úteis no desenvolvimento de aplicações web não distribuídas. Por exemplo, CDInão fornece controle de transações automaticamente; EJBs, por outro lado, podem fazer gerenciamento de transações de maneira declarativa e quase transparente. Algumas funcionalidades de EJB úteis para grandes aplicações corporativas também não têm contrapartidas imediatas em CDI. É o caso dostimers, que permitem agendar a execução de métodos de beans para momentos específicos. Outra funcionalidade relevante são os métodos assíncronos. Estes métodos, quando invocados, não bloqueiam a thread; ao invés disto, são executados paralelamente e seus resultados podem ser recuperados posteriormente. Provavelmente, porém, a maior deficiência de CDI, quando comparado com EJBs, seja a falta de facilidades para progra mação distribuída. Não é possível invocar beans gerenciados em servidores diferentes de maneira transparente, por exemplo. Outros recu rsos, como monitoração d e beans via JMX, também estão ausentes, dificultando a depuração e monitoramento de aplicações. CDI tampouco suporta pooling de instâncias e beans gerenciados não são encontráveis via JNDI nem invocáveis via JMS. Muitas destas funcionalidades podem ser providas por extensões de CDI ou outras bibliotecas. Por exemplo, o projeto Apache MyFaces CODI, que é um conjunto de extensões para CDI, provê uma anotação @Transactional que declarativamente envolvebeans ou métodos em transações. Timers podem ser substituídos pelo agendador Quartz; o projeto teria mais uma dependência, mas Quartz é em si bem poderoso, até mais que os timers. Métodos assíncronos, por sua vez, podem ser implementados com threads. Por fim, há extensões para tornar beans CDI mais fáceis de acessar remotamente – boa parte delas oriundas do claudicante projeto
que, da situação, podem ser bemdemais Comodependendo é usual, interceptadores e decoradores CDIadequados. podem ser aplicados a EJBs também. Os criadores de CDI enfatizam bastante, tanto na JSR quanto nas documentações de referência, que a nova tecnologia não veio para substituir EJBs. Entretanto, CDI é bastante semelhante a frameworks como Spring, Seam e Guice, que se consolidaram como alternativas práticas a EJB. Oras, estes frameworks – e, por extensão, CDI – são frequentemente considerados como uma
Seam 3 – comoestarão RESTEasy CDI e Seam JMS. Futuramente, ainda mais módulos disponíveis. Entretanto, é razoável se perguntar se realmente compensa utilizar estas extensões em boa parte dos casos. Muitas, talvez a maioria, destas extensões ainda está em amadurecimento ou têm futuro indefinido, como as providas por Seam 3. Além disto, CDI integra muito bem com EJB, de modo que é possível delegar aos EJBs o que CDI não pode fazer. Como EJB 3.1 é muito simples de utilizar e EJB lite é relativamente fácil de ser implantado até em
- Beans gerenciados (managed beans) são todos os beans criados e gerenciados por CDI. Podem ser tanto EJBs quanto POJOs que satisfaçam umas poucas condições (ser classe concreta, possuir construtor padrão, etc.).
Outro ponto em que CDI reimplementa funcionalidades de EJB de maneira superior é o gerenciamento de ciclo de vida de beans. Enquanto beans de sessão podem ser apenas stateless (criado e destruído a cada acesso), stateful (criado e destruído quando o desenvolvedor determina) ou, em EJB 3.1,singletons, um bean gerenciado pode ter praticamente qualquer ciclo de vida. Para nos restringirmos apenas aos já providos porCDI, umbean gerenciado pode estar em um dos seguintes escopos: • Escopo de requisição: quando é insta nciado e destruído a cada requisição; • Escopo de sessão: quando é associado a uma sessão e destru ído junto com ela; • Escopo de aplicação: quando sobrevive por todo o período de execução da aplicação; ou • Escopo de conversação: geralmente associado a uma aba de navegador, e passível de ser destruído pelo programador.
16 Java Magazine
•
Edição 105
contêineres de servlets, não é absurdo se cogitar o uso de CDI com esquematicamente pela Figura 5 , a Figura 6 mostra graficamente EJB, o que é, por sinal, a recomendação dos grandes patrocinadores a arquitetura ECB. de Java, como Oracle e JBoss.
Usando EJB com CDI De fato, utilizar EJB 3.1 e CDI pode tornar o desenvolvimento muito mais simples. Por exemplo, considere a classe PessoaDAO da Listagem 3 . A classe tem a responsabilidade de persistir uma entidade chamada Pessoa no banco de dados; entretanto, o código apresentado fatalmente falharia, porque nãohaverá nenhuma transação aberta. Uma solução seria gerenciar as transações manualmente, o que seria trabalhoso e prolixo. Outra opção seria usar uma extensão de CDI, como o Hibernate CDI ou MyFaces CODI. Listagem 3.Classe de DAO sem gerenciamento de transações.
public class PessoaDAO { @PersistenceContext(unitName=”GerenciadorEntidade”) private EntityManager entityManager; public void atualizar(Pessoa pessoa) { entityManager.merge(pessoa); } }
Figura 5. Representação esquemática de uma aplicação MVC
A simplicidade de EJB 3.1
A terceira opção seria transformarPessoaDAO em um EJB. O desenvolvedor Java EE antigo pode imaginar que isto é excessivamente complexo para um problema tão si mples, mas em Java EE 6 esta é, de fato, a solução mais simples: basta anotar a classe com@Stateless: @Stateless public class PessoaDAO
E é isto: nosso EJB está pronto, com controle de transações; como EJBs são tambémbeans gerenciados de CDI, é possívelinjetar nosso PessoaDAO em qualquer outrobean CDI e injetar qualquer bean gerenciado em PessoaDAO. O modelo Entity-Control-Boundary
No nosso exemplo, utilizamos EJBs para gerenciamento de transações, mas poderíamos converter nosso bean em um EJB para criar métodos assíncronos, torná-lo acessível via JMS, acrescentar um timer etc. O mais f requente, porém, em aplicações web de complexidade média, é utilizar EJBs por serem transacionais, mas de acordo com o modeloEntity-Control-Boundary (ECB), uma variante do modelo MVC. possui três camadas antes do view: Neste modelo, a aplicação camada de entidades (que contém elementos persistentes ou objetos não gerenciados), camada de fronteira (cujos componentes são acessados por código cliente) e camada de controle (que intermedeia fronteira e entidade). A lógica de apresentação está isolada no view, que utiliza a camada de fronteira. Por sua vez, a lógica de negócio é implementada nas camadas de entidade, controle e fronteira. Se uma aplicação MVC pode ser representada
Figura 6. Representação esquemática de uma aplicação ECB. - A grande vantagem do modelo ECB é a separação entre a lógica de negócio e a lógica de apresentação. Esta separação é importante porque o código da interface de uma aplicação tende a mudar muito, ao contrário da lógica de negócio, que é mais estável.
Se nosso exemplo for convertido ao modelo ECB, a classe Pessoa pertenceria à camada de entidade, ePessoaDAO pertenceria à camada Edição 105 Java Magazine •
17
EJB 3.1 versus CDI
de controle. Haveria, porém, uma nova classe, chamada, digamos, PessoaFacade , que seria a camada de fronteira. Nesta arquitetura, o EJB não seria mais PessoaDAO, mas sim PessoaFacade . Isto faz sentido porque se, digamos, executarmos um método que faça duas operações de persistência, e a segunda operação falhar, provavelmente será necessário que ambas as operações sejam canceladas, pois a primeira operação só faria sentido junto com a segunda. A classe PessoaFacade é apresentada na Listagem 4 .
Java EE para injeção de dependências e gerenciamento de contexto. CDI inspira-se em muitosframeworks bem-sucedidos de terceiros, que já resolvem inúmeros dos problemas que Java EE atacava há um bom tempo. Os programadores Java para web não puderam deixar de se perguntar, então: é possível substituir EJBs por CDI? Em boa parte dos cenários, é possível sim abandonar EJBs, pois muitos dos seus recursos já são fornecidos por CDI. É verdade que há funcionalidades de Enterprise JavaBeans que não são supridas por CDI (ao menos não ainda), tais como gerenciamento de tran- Outra vantagem de usar EJBs na camada de fronteira é que isto permite que os sações; entretanto, são frequentemente fáceis de implementar e serviços sejam providos remotamente, sejam distribuídos etc. Considerando que um rico ecossistema de extensões para CDI está florescendo. Se o custo de criar EJBs em Java EE 6 é baixo, pode ser uma boa estratégia. você deseja gerenciamento declarativo de transações, por exemplo, basta usar projetos como MyFaces CODI. O papel de CDI neste cenário é fazer o que melhor faz: servir de Por outro lado, o desenvolvedor pode ter muito a ganharse der uma cola entre os componentes da aplicação. Os componentes internos chance a EJB 3.1. De fato,o desenvolvimento de EJBs na nova versão é beans gerenciados por CDI, e EJB tem do software não precisarão ser mais EJBs e serão injetados via tão simples quanto a criação de CDI, que é vantajoso até mesmo para fazer injeção de dependêna vantagem de já estar disponível em servidores de aplicação. Muitos cias em EJBs, como pode ser visto na Listagem 4 . CDI também dos problemas que demandariam extensõesde CDI são resolvíveis ficaria responsável por processar eventos, executar intercepta– e, o mais importante,facilmente resolvíveis – com EJB 3.1. dores e decoradores, gerenciar ciclo de vida, entre outros. Caso Resumindo, o desenvolvedor JavaEE tem duas escolhas: utilizar um componente interno da aplicação venha a necessitar de uma CDI com extensões ou utilizar EJB 3.1 com CDI – ambas as soluções funcionalidade de EJBs, adaptá-lo pode ser tão simples quanto são viáveis. É recomendável, porém, que o programador avalie se acrescentar a anotação @Stateless . EJB é uma solução para seu problema. No final das contas, esta é a melhor notícia: EJB pode ser a solução, agora, e não mais um problema por si só. Listagem 4.Classe de facade, que cumpre o papel de fronteira na arquitetura ECB
de nosso projeto.
Adam Victor Nazareth Brandizzi
@Stateless public class PessoaFacade { @Inject private PessoaDAO pessoaDAO; public Pessoa criar(String nome, String usuario, String senha, int idade) { return pessoaDAO.criar(nome, usuario, senha, idade); } public List getTodas() { return pessoaDAO.recuperarTodas(); }
É desenvolvedor em várias linguagens. Programa em Java há quatro anos, trabalhando majoritariamente com Struts 2 e com a ferramenta de portais Liferay. É licenciado em Computação pela Universidade de Brasília e atualmente trabalha para SEA Tecnologia. http://jcp.org/en/jsr/detail?id=299
JSR 299 - a especificação de CDI. http://docs.jboss.org/weld/reference/1.0.0/en-US/html/
}
Manual de referência de Weld, a implementação de referência de CDI. http://www.devmedia.com.br/post-18231-CDI-Contextos-e-Dependencias.html
Conclusões Java sempre teve o estigma de ser uma linguagem complicada, e a plataforma Java EE era emblemática neste sentido. Muitas de suas tecnologias centrais, como EJBs, eram extremamente complexas, trabalhosas e confusas. Java EE 6, porém, reverte boa parte deste quadro, ao trazer evoluções de framewor ks de terceiros para as
CDI - Contextos e Dependências (Artigo da Java Magazine 84 explicando como utilizar CDI). http://www.adam-bien.com/roller/abien/entry/simplest_possible_ejb_3_15
Artigo de Adam Bien explicando como usar CDI com E JB. http://myfaces.apache.org/extensions/cdi/
especificações especiais, EJB além3.1. deEsta reformar antigas. Página do projeto Apache MyFaces CODI. Por exemplo, considere versãotecnologias de EJBs, que faz parte de Java EE 6, torna ainda mais simples a versão anterior da tecnoloDê seu feedback sobre esta edição! gia, EJB 3.0, que já tinha tornado EJBs praticamente irrecon hecíveis A Java Magazine tem que ser feita ao de tão simples, quando comparados com versões anteriores. seu gosto. Para isso, precisamos saber Entretanto, o caráter obscuro e trabalhoso dos EJBsantigos era tão o que você, leitor, acha da revista! traumatizante que os desenvolvedores Java EE ainda buscam maneiras de evitar ter de lidar com EJBs, mesmo na nova versão. Isto se Dê seu voto sobre este artigo, através do link: tornou ainda mais desejável com a introdução de CDI, a especificação www.devmedia.com.br/javamagazine/feedback
18 Java Magazine
•
Edição 105
Edição 105 Java Magazine •
19
a v a J o ã ç e S
NESTA SEÇÃO VOCÊ ENCONTRA ARTIGOS INTERMEDIÁRIOS E AVANÇADOS SOBRE JAVA
Por dentro do JavaFX 2 Uma nova plataforma para odesenvolvimento de aplicações ricas para web
D
esde a popularização da Internet, vemos uma tendência crescer de maneira constante: a convergência de aplicativos, anteriormente “isolados” em um computador desconectado, para a “Web”. Dentro da janela de um navegador, não são somente sites que prendem a atenção do usuário – agora, aplicativos, jogos e conteúdo multimídia “saltam” literalmente da Internet para o computador do usuário. Essa tendência de criação de aplicações Web cada vez mais parecidas (e atémesmo equivalentes ou superiores) com outros programas tradicionalmente não dependentes da Internet – e que são costumeiramente chamados de “aplicativos desktop” – culminou com o aparecimento de uma nova categoria de aplicativos, a dos aplicativos ricos para a Internet (Rich Internet Applications, ou simplesmente RIA). A ideia por trás deste tipo de aplicativo é justamente dar ao usuário os mesmos recursos e a mesma sensação de utilização que ele possui com um aplicativo desktop tradicional, desfrutando das óbvias vantagens da conexão à r ede. Um aplicativo deste tipo, por ser executado na maioria dos casos “dentro” de um navegador, torna-s e acessível em qualquer loc al onde o usuário tenha acesso a um browser e uma conexão à Internet. Uma outra característica marcante da aplicação rica para a Internet é que esta geralmente faz uso intenso de animações e gráficos em alta qualidade – tanto que, atualmente, alguns dos exemplos mais populares de aplicativos nesta categoria são jogos e programas com uso abundante de recursos de multimídia. Este conceito das Rich Internet Applications , apesar de ser desconhecido por muitos, não é novo. Programas deste tipo têm sido desenvolvidos há anos, por meio
A plataforma Adobe Flash é uma “velha conhe cida” dos desenvolvedores Web; com ela, os mais variados tipos de aplicativos são desenvolvidos atualmente, de jogos e soft wares multimídiaa aplicativos tradicionais, por meio do uso do AIRAdobe ( Integrated Runtime). A aposta da Microsoft em RIA, o Silverlight, foi lançado em Abril de 2007 e é um competidor direto do Adobe Flash. Em seu benefício, está a possibilidade de criação de aplicativos usando as linguagens do framework .NET e o Visual Studio como ferramenta
de plug-ins para navegadores o Adobe Flash), virtualização e uso intenso de (como JavaScript e Ajax. Atualmente, as três plataformas mais utilizadas para desenvolvimento de aplicações ricas para a Internet são (por taxa de presença no mercado – http://www.statowl. com/custom_ria_market_penetration.php ): • Adobe Flash (95.60 %); • Java (75.81 %); e • Microsoft Silverlight (67.32 %).
deO desenvolvimento. Java ocupa a segunda posição nesta estatística, com o diferencial de ser já “veterana” neste quesito – afinal de contas, applets Java são usados há anos para desenvolvimento de aplicações ricas para a Internet. Mas além dos applets, uma nova alternativa para desenvolvimento de aplicações ricas em Java foi apresentada em Maio de 2007 pela então Sun (hoje, como sabemos, incorporada pela Oracle): o JavaFX.
20 Java Magazine
•
Edição 105
Resumo DevMan De que se trata o artigo: O artigo apresenta a tecnologia JavaFX 2.0,voltada ao desenvolvimento de aplicações cliente ricas para a Internet em múltiplas plataformas. Para isso, uma introdução à tecnologia, seu histórico e principais recursos são apresentados, junto aexemplos práticos onde são demonstradas algumas das suas funcionalidades.
Em que situação o tema é útil: A criação de aplicações cliente ricas é hoje um segmento em ascensão na área de desenvolvimento de software. Os programadores Java contam agora com o JavaFX 2.0 como uma nova opção, poderosa e flexível, nesta área.
Por dentro do JavaFX 2: A tecnologia JavaFX, recentemente atualizada para a versão 2.0, possibilita a criação de aplicações cliente ricas para a Internet utilizando um novo conjunto de controles e recursos gráficos, aliados às vantagens da linguagem Java que já são familiares aos desenvolvedores. Não são somente aplicações gráficas e jogos que podem tirar proveito da tecnologia. Qualquer tipo de software cliente pode ser desenvolvido utilizando seus recursos e evidentes vantagens na elaboração de uma rica interface.
O que é JavaFX: introdução e um breve histórico Nas palavras da própria Oracle, JavaFX é “o próximo passo na evolução do Java como plataforma de desenvolvimento de aplicações cliente ricas”. E a Oracle vai ainda mais longe: no item 6 do FAQ do JavaFX (http://www.oracle.com/technetwork/java/javafx/overview/faq-1446554.html), a empresa indica que a tendência é o JavaFX assumir o posto do Swing como principal biblioteca de interface do usuário da linguagem. Isso não quer dizer pouca coisa. Inicialmente apresentada em maio de 2007, a primeira versão oficial (1.0) só foi disponibilizada pela Sun em dezembro de 2008. Nas suas primeiras versões, antes da chegada da 2.0, os aplicativos JavaFX eram criados em uma linguagem de scripting específica, denominada JavaFX Script. O código escrito nesta linguagem era posteriormente compilado em bytecode, podendo ser executado em qualquer sistema com o Java Runtime instalado. Mantendo a tradição do Java, uma aplicação rica JavaFX pode ser executada em plataformas distintas, como celulares com Java ME, sistemas operacionais da famí lia Windows e variações de Unix (Linux, Solaris e Mac OS X). O lançamento da versão 2.0 marcou uma mudança significativa no JavaFX, já que a partir dela as aplicações puderam passar a ser escritas em código Java nativo. O suporte ao JavaFX Script foi removido nesta versão, mas graças à disponibilização pública do seu código-fonte em 2007, ganhou uma possibilidade de “sobrevida” com a ajuda da comunidade (como por exemplo o projeto Visage – http://code.google.com/p/visage/). Agora, com o JavaFX 2, a solução é apresentada como a forma do programador Java “tradicional” reaproveitar seu conhecimento na linguagem para o desenvolvimento de aplicações ricas.
Características e recursos do JavaFX
“tradicionais” (usando controles padrão, como botões e caixas de texto), quanto no uso de desenhos, animações e gráficos 3D; • Um novo mecanismo de mídia, para reprodução de áudio, vídeo e streaming; • Fácil integração com aplicações e controles Swing existentes; • Um novo plug-in para os browsers, que visa aumentar o desempenho na execução das aplicações JavaFX e utilizar as vantagens da aceleração gráfica.
Figura 1. Tela do exemplo Ensemble, fornecido pela Oracle, apresentando um gráfico criado em JavaFX 2.0
Assim como outras tecnologias similares, como o Adobe Flash, o JavaFX é também ideal para criação de jogos, dos mais simples (Figura 2 ) aos mais complexos, utilizando o já comentado suporte à aceleração gráfica por hardware.
O JavaFX traz uma série de características e recursos interessantes aos desenvolvedores, sejam eles programadores Java ou não, como por exemplo: • Um conjunto de mais de cinquenta controles totalmente “repagi nados”, incluindo os tradicionais (como botões, caixas de entrada de texto, etc.) e outros mais sofisticados, como gráficos F( igura 1), tabelas e até mesmo uma versão do popular “acordeão” (accordion) encontrado em bibliotecas JavaScript. Afinal de contas, uma aplicação séria e detalhista, como, por exemplo, uma que demonstra os indicadores financeiros de uma empresa, não precisa ser necessariamente feia; • Drag and drop de aplicativos: uma aplicação JavaFX executada dentro de um navegador pode facilmente ser “arrastada” até a área de trabalho, ou outra pasta qualquer, e posteriormente ser executada necessidade doabrowser; • A partir sem da versão 2.0, com mudança de JavaFX Script para código Java nativo, fica ainda mais intuitiva e rápida a familiarização de usuários veteranos da linguagem com a nova tecnologia; • Uma separação da interface gráfica e da lógica realizada adequadamente. Para isso, o JavaFX traz a FXML – uma linguagem de marcação baseada em XML para definição da interface; • Mecanismo de aceleração gráfica que aproveita diretamente os recursos das GPUs mais modernas, tanto nas interfaces mais
Figura 2. Tela do exemplo BrickBreaker, fornecido pela Oracle
Todas estas vantagens já estão disponíveis aos desenvolvedores, nas principais plataformas (Windows, Linux – este ainda em versão preview – e Mac OS X), já que o JavaFX 2.0 está incluído diretamente no JDK 7. Edição 105 Java Magazine •
21
Por dentro do JavaFX 2
Quanto às ferramentas de desenvolvimento, o NetBeans, na versão 7.1.2 (a mais atual no momento da elaboração deste artigo), possui suporte completo àcriação de projetos JavaFX 2,bem como à depuração dos mesmos. Para criação das interfaces gráficas, a Oracle disponibiliza o JavaFX Scene Builder. Com ele, o desenvolvedor pode montar sua interface graficamente, “arrastando” os controles pela tela, e o código apropriado em FXML será gerado automaticamente.
javafx. scene.me dia: Media , para representar um arquivo; MediaPlayer , para reproduzi-los; e MediaView, para exibir a mídia como um nó
de cena.são Osinseridos controlescomo visuais dono JavaFX, parte do toolkit dejanelas Glass, nós gráfico de cena. A aparência destes controles pode ser definida por meio de folhas de estilo CSS, o que facilita a padronização e configuração da interface do aplicativo. Com relação à mídia, existe suporte nativo para arquivos de áudio em formato MP3 e WAV, bem como para vídeos no formato FLV. A reprodução de arquivos de mídia é extremamente simples, bastando para isso usar as classes existentes no pacote
Instalando e testando o JavaFX 2
no gráfico de cena. Como se trata de uma arquitetura multiplataforma, também são disponibilizados layouts para um correto e flexível agrupamento dos controles visuais dentro do gráf ico de cena. Estas class es, do tipo “container ”, estão dispon íveis no pacote java fx. scene.layout . Seguindo o preceito que uma plataforma de aplicações ricas deve Arquitetura do JavaFX utilizar bastante os recursos gráficos, não faltam ao JavaFX classes O JavaFX possui uma arquitetura interna dividida em camadas, para transformação 2D e 3D, assim como diversos efeitos visuais. onde, como base principal, está a máquina virtual JavaFigura ( 3). Com as classes do pacote javafx. scene.trans form , é possível realizar No centro da arquitetura estão os componentes responsáveis pela a translação e rotação de um nó no gráfico de cena, nos eixos x, renderização gráfica (Prism), o toolkit de janelas (Glass) e os me- y e z. Já no pacote javafx. scene.ef fects , encontram-se classes para a canismos de suporte à multimídia e interface Web. Na parte mais aplicação de diversos efeitos gráficos em um nó, como sombra e externa, encontram-se as APIs públicas do JavaFX e o gráfico de reflexo, por exemplo. cena (Scene Graph). Um outro elemento importante da arquitetura do JavaFX 2 é a O gráfico de cena é uma estrutura hierárquica composta por linguagem de marcação FXML. Baseada em XML, ela é utilizada nós (“nodes”) – os elementos da interface do usuário. Para cada para definição da interface de u ma aplicativo JavaFX. Criar uma um destes elementos são definidas propriedades e eventos, assim interface JavaFX usando FXML, e não diretamente pelo código como se faz no tradicional toolkit Swing. Complementando o Java (o que também é perfeitamente possível), traz a vantagem gráfico de cena, na mesma camada, está a API pública do JavaFX, da separação entre a lógica da aplicação e a definição da sua constituída de classes para animações, mídia e interação com os aparência. Dentro do padrão de desenvolvimento em camadas controles visuais, entre outras. MVC (Model-View-Controller), pode-se dizer que a interface em FXML se encaixa como a visão ( View) da aplicação. Um arquivo com a definição FXML de uma tela pode ser criado diretamente em código XML, por meio de um editor de texto simples, ou com o uso do JavaFX Scene Builder. Com este último, o usuário cria a tela arrastando e posicionando os controles visuais, e o código FXML é gerado automaticamente. Não existe nada melhor para conhecer uma nova plataforma de desenvolvimento do que “por as mãos na massa”. Visando proporcionar um melhor entendimento do JavaFX, de sua arquitetura e Figura 3. Diagrama da arquitetura do JavaFX 2 (adaptado da documentação da Oracle) funcionalidades, serão demonstrados a seguir exemplos práticos que abrangem os conceitos fundamentais na elaboração de um O sistema gráfico do JavaFX está indicado pelos elementos de aplicativo baseado nesta tecnologia. cor azul-escuro no diagrama da Figura 3 . O Prism é um elemento fundamental nesta estrutura, sendo responsável pelarenderização gráfica, utilizando para istoDirectX em sistemas Windows, OpenGL em Mac e Linux, e Java2D quando a aceleração por hardware não está disponível. O Toolkit Quantum é o responsável por unir o Prism, o toolkit Tutorial de janelas Glass, o mecanismo de mídia e o mecanismo de Web, para então disponibilizá-los à camada da API pública e do gráfico
22 Java Magazine
•
Edição 105
Para desenvolver aplicativos em JavaFX, inicialmente, era necessário obter o SDK apropriado como um download à parte. Porém, as versões mais recentes do JDK 7 para sistemas operacionais Windows e Mac OS X já trazem o JavaFX SDK integrado. Para sistemas Linux, está disponível uma versão beta, denominada JavaFX Developer Preview (o endereço para download está disponível na seção Links , no final do artigo).
Os exemplos aqui demonstrados foram criados e testados com a versão 7u4 do JDK, que inclui o JavaFX 2.1 (Figura 4 ), junto com o NetBeans 7.1.2. Para garantir total compatibilidade com os exemplos que serão apresentados aqui, recomenda-se o uso de versões iguais ou superiores a estas.
Na próxima tela, informe o nome do projeto como “AloMundoFX” (Figura 6 ). Uma aplicação JavaFX, especificada pela classe javafx. applica tion.Ap plication , contém sempre um Stage, que pode ser definido como o container superior de todos os objetos da tela (ou seja, uma janela – à grosso modo). Dentro de um Stage, por sua vez, fica uma Scene, que conterá os controles visuais, como botões e rótulos de texto. Na criação do projeto, o nome especificado para ele será usado automaticamente como o nome da sua classe Application . Clique então em Finalizar.
Figura 4. Tela inicial da instalação do JDK 7u4, que inclui o JavaFX 2.1 (em destaque)
Após o encerramento da instalação padrão do JDK 7u4, será apresentada a tela de instalação do JavaFX 2.1. Assim como no caso do JDK, basta prosseguir clicando em Next (Figura 5 ). Ao finalizar a instalação, o sistema já estará pronto para executar e compilar aplicativos JavaFX. Para a criação dos exemplos, será utilizado o NetBeans versão 7.1.2, que tem suporte completo para a criação de aplicativos JavaFX 2.1. O primeiro exemplo consiste em uma “versão JavaFX” do tradicional “Alô, mundo”, com o objetivo de testar se a instalação da plataforma foi realizada corretamente. Assim, no NetBeans, clique no menu Arquivo | Novo projeto.... Na janela que será exibida, selecione a categoria JavaFX, à esquerda, Aplicativo JavaFX, à direita, e clique em Próximo (Figura 5 ).
Figura 5. Criando um novo projeto JavaFX
Figura 6. Definição do nome do novo projeto
Como pode ser visto na aba Projetos do NetBeans, a estrutura inicial de um projeto JavaFX é bastante simples – contém apenas a biblioteca principal da plataforma e o arquivo com o código da Application . Todo projeto JavaFX criado pelo NetBeans contém um modelo básico de código que já está pronto para ser executado e pode servir perfeitamente para testar a plataforma. Deste modo, pressione a tecla F6 ou clique no botão Executar projeto principal do NetBeans para executá-lo (lembre-se que, caso tenha mudado seu projeto principal, clique com o botão direito do mouse sobre o projeto AloMundoFX e selecione Definir como projeto principal). Em poucos segundos uma janela com a aplicação JavaFX será aberta, e ao clicar no botão “Say ‘Hello world’”, esta mensagem será exibida no console, logo abaixo (Figura 7 ). Vamos incrementar um pouco mais esta aplicação. Ao invés de exibirmos a mensagem “Hello World!” noconsole, vamos mostrar “Alô mundo!” dentro da janela, usando um controle Label do pacote javafx. scene.contro l. Para deixar o aplicativo com mais “cara de JavaFX”, aplicar um efeito DropShadow (“Sombra”), existente javafx. scene.ef fect , neste Label . no pacotevamos Antes de passarmos ao código-fonte, é necessário entender um conceito importante em um aplicativo JavaFX – a relação entre as classes Scene e Stage, usadas na definição da tela. Como foi abordado no tópico relativo à arquitetura do JavaFX, os elementos visuais do aplicativo são construídos em um gráfico de cena (Scene Graph). Este termo é um “velho conhecido” dos pesquisadores de programação gráfica e realidade virtual, Edição 105 Java Magazine •
23
Por dentro do JavaFX 2
e é usado para determinar a estrutura hierárquica de elementos visuais em uma imagem ou tela. No JavaFX, um gráfico de cena é usado para definição de uma tela do aplicativo, por meio do uso da classe Scene. Um objeto desta classe é, portanto, um gráfico para uma cena (ou tela) dentro programa. Já a classe Stage funciona como o “container” de uma Scene . De fato, uma
das traduções para a palavra “stage” é, literalmente, “palco”.O Stage é, deste modo, o “palco” onde a(s) cena(s) acontecem. Dentro dele, é colocada aScene, e dentro da Scene, são inseridos os demaiscontroles, como rótulos e botões. O Stage funciona, sob o ponto de vista de uma aplicação desktop tradicional, como sua janela principal. Com os conceitos de Stage e Scene definidos, podemos passar para a codificaç ão.
Assim sendo, modifique o código-fonte da sua classe AloMundoFX de modo que ele fique como o apresentado na Listagem 1 (note que os comentários foram removidos para reduzir o tamanho da listagem). Neste primeiro projeto, é importante ter um entendimento específico sobre cada uma das linhas do código: Linhas 3 a 14: são realizados os imports para as classes utilizadas no programa; Linha 16: a classe AloMundoFX herda a Application , de javafx.app lication. Esta é a classe base de uma aplicação JavaFX – é o seu ponto de entrada; Linhas 18 a 20: o método main() invoca o método launch(), passando os argumentos recebidos. É delaunch(), herdado de Application, a tarefa de iniciar a aplicação; Linha 23 : é no método start() , reescrito da superclasse Application , que deve ser colocado o código inicial da aplicação. Este método, invocado automaticamente na sequência de inicialização do aplicativo, recebe o Stage principal da aplicação como parâmetro, onde a cena deverá ser construída; Linha 24: o método setTitle() define o texto da barra de título do Stage (janela) principal; •
•
•
•
•
Figura 7. Execução da aplicação AloMundoFX Listagem 1.Código da classe AloMundoFX.
btn.setText(“As palavrinhas mágicas são...”); DropShadow sombra = new DropShadow(); sombra.setOffsetY(3.5); sombra.setColor(Color.color(0.5, 0.5, 0.5)); final Label lab = new Label(); lab.setEffect(sombra); lab.setTextFill(Color.STEELBLUE); lab.setFont(Font.font(null, FontWeight.BOLD, 42)); lab.setCache(true); btn.setOnAction(new EventHandler() { @Override public void handle(ActionEvent event) { lab.setText(“Alô mundo!”); } }); VBox raiz = new VBox(); Scene cena = new Scene(raiz, 300, 100); raiz.getChildren().add(btn); raiz.getChildren().add(lab); stagePrincipal.setScene(cena); stagePrincipal.show(); } }
Linha 25: cria uma instância de javafx. scene.contr ol.Button , com o nome btn; Linha 26: define o texto que aparecerá dentro do botão (o seu rótulo); Linha 27: instancia um objeto javafx. scene.ef fect.D ropShadow, com o nome sombra; Linha 28: define o offset (deslocamento) da sombra no eixo Y. Linha 29: define a cor da sombra. A cor é indicada como três valores double , entre 0.0 e 1.0, representando, respectivamente, vermelho, verde e azul; Linha 30: cria uma instância final de um objeto javafx.sce ne.control. Label , onde será exibida a mensagem “Alô mundo!”; Linha 31: define o efeito a ser usado no Label. No caso, o efeito de sombra criado anteriormente; Linha 32: configu ra a cor de preenchimento do texto para Color. STEELBLUE; Linha 33: define a fonte a ser usada no texto. Isso é realizado por meio do método estáticofont(), da classe Font, que recebe como parâmetros: - null: o primeiro parâmetro indica o nome da família de fontes desejada. O valornull determina que o runtime do JavaFX utilizará uma fonte padrão; - FontWeight.BOLD: o segundo parâmetro determina que será usada uma versão em negrito da fonte escolhida; - 42: valor double indicando o tamanho da fonte, em pontos. Linha 34: o método setCache() é importante por razões de desempenho. Ele determina que o bitmap gerado pelo desenho do texto e seu efeito serão salvos em cache, evitando a necessidade de renderizá-lo novamente quando não for necessário; Linhas 35 a 41: define um manipulador de evento para o botão. Assim como os eventos que já conhecemos no Swing e em outras plataformas, será disparado quando a açãofor realizada no objeto receptor (neste caso, quando um “Action Event”, como o clique do mouse, ocorrer no botão); Linha 43: instancia um objeto javafx. scene.layo ut.VBox. Um layout VBox (“Vertical Box”) alinha seus objetos em uma coluna, um abaixo do outro; Linha 44: cria o objeto que representa a cena na interface. O construtor utilizado recebe três parâmetros: o nó “raiz” da cena – no caso, o layoutVBox; a largura da cena em pontos; e sua altura, também em pontos; Linhas 45 e 46: adicionamos o botão btn e o rótulo de texto lab aos “filhos” do layoutVBox. Eles serão “empilhados”, de cima para baixo, na ordem em que são adicionados; •
•
•
• •
•
•
Figura 8. Tela do aplicativo AloMundoFX
Com as classes, métodos e conceitos que vimos neste aplicativo simples, pudemos não somente testar o JavaFX, mas conhecer um de seus conceitos fundamentais: a relação entre o Stage, a Scene e os controles. Poderíamos sumarizar esta relação, de maneira simplificada, de acordo com o diagrama da Figura 9 .
•
•
•
•
•
•
•
Stage precisa saber qual é sua cena. Por isso invocamos Linha 47: osetScene() seu método , passando nosso objeto cena como, parâmetro; Linha 48: fina lmente, o método show() do Stage principal é invocado, exibindo a janela. •
•
O resultado da execução do código da Listagem 1 pode ser observado na Figura 8 . Repare na qualidade da renderização do texto e sua sombra. Digna da qualidade obtida em um aplicativo de desenho ou manipulação de imagens.
Figura 9. Estrutura da interface gráfica de uma aplicação JavaFX
Esta abordagem de criação e configuração dos controles visuais dentro do código-fonte Java é válida, e perfeitamente justificável em alguns casos. Porém, na maioria das vezes, é mais interessante separar a lógica do programa da definição de sua interface, obedecendo aos preceitos de padrões de desenvolvimento como o MVC.
Uma aplicação JavaFX dividida em camadas No exemplo anterior, criamos uma aplicação JavaFX onde os seus componentes de interface são criados e dispostos na tela diretamente por código Java. Agora, veremos como uma aplicação semelhante poderá ser criada com uso da FXML, a linguagem de marcação baseada em XML que o JavaFX usa na definição das interfaces. | Novo projeto.... Na Portanto, abrado o NetBeans e clique emArquivo JavaFX na categoria, à tela de escolha tipo de projeto, selecione esquerda. No tipo de projeto, à direita, marque Aplicativo FXML do JavaFX. Depois clique no botão Próximo (veja a Figura 10 ). Na tela seguinte, defina o nome do projeto como “AloMundoFXML” e clique emFinalizar. Será criada uma estrutura de projeto como a indicada na Figura 11 . Agora, ao invés de um único arquivo, como tínhamos no AloMundoFX anterior, temos três arquivos dentro do pacote:
Edição 105 Java Magazine •
25
Por dentro do JavaFX 2
• AloMundoFXML.java : contém a classeAppli-
cation, por onde o aplicativo é inicializado –
assim como tínhamos no projeto anterior; • Sample.fxml : contém a especificação em FXML (que, como já vimos, baseia-se em XML) da cena que define a tela do aplicativo. No padrão MVC, este arquivo corresponde à camada de visão do nosso aplicativo; • Sample.java: esta classe é onde colocaremos os métodos associados aos eventos da tela, ou seja, a interação do usuário com o aplicativo por meio do mouse e do teclado. Dentro do MVC, este arquivo representa o controlador da visão.
Figura 10. Criando um projeto JavaFX com interface em FXML
Essa aplicação será semelhante à anterior, entretanto, além de entendermos como funciona o uso dosarquivos FXML, vamos dar uma “incrementada” nela: O usuário poderá inserir a mensagem desejada, usando um componente caixa de texto; Utilizaremos outro efeito para o texto: o reflexo. •
•
Figura 11. Estrutura de arquivos do projeto AloMundoFXML Listagem 2.Código da classe AloMundoFXML.
package alomundofxml; import javafx.application.Application; import javafx.fxml.FXMLLoader; import javafx.scene.Parent; import javafx.scene.Scene; import javafx.stage.Stage; public class AloMundoFXML extends Application { public static void main(String[] args) { } Application.launch(AloMundoFXML.class, args); @Override public void start(Stage stage) throws Exception { Parent root = FXMLLoader.load(getClass().getResource(“Sample.fxml”)); stage.setTitle(“Gerador de texto artístico!”); stage.setScene(new Scene(root)); stage.show(); } }
26 Java Magazine
•
Edição 105
O arquivo AloMundoFXML.java, gerado automaticamente pelo NetBeans, precisa de apenas uma pequena alteração: mudar o título da janela. Portanto, adapte sua classe de modo que ela fique como a apresentada na Listagem 2 . Como podemos reparar, o código é bastante semelhante ao utilizado no exemplo anterior. A única diferença significativa está na linha 17. Nela, utilizamos o método load() da classe FXMLLoader para carregar o layout da tela existente no arquivoSample. fxml. Este método retorna uma referência ao objeto raiz da hierarquia do gráfico de cena, que é armazenada na variável root. Posteriormente, nalinha 19 , definimos a cena do Stage principal. Ela será criada utilizando o nó root como seu nó raiz. Agora vamos modificar interface do aplicativo. Para isso, abra o aarqu ivoSample. fxml, clicando duas vezes sobre ele, e modifique de acordo com a Listagem 3 . Alteramos apenas alguns poucos elementos do exemplo srcinal. Primeiramente, precisamos adicionar dois novos imports , para utilizarmos as classes de efeitos e fonte (linhas 7 e 8 ).
é indicado o nome do método que será disparado, dentro do controlador (Sample.java), quando o botão receber uma ação (no caso, um clique). O programador pode especificar um nome qualquer para o manipulador do evento, desde que o valor aqui especificado corresponda a um método existente no controlador Sample.java. Na linha 14 é definido o rótulo de texto (Label) que exibirá a mensagem. Aqui, é possível realizar todas as configurações de estilo feitas pelo código Java no exemplo anterior, como, por exemplo, a cor de preenchimento do texto, indicada em valor RGB no atributo textFill. Repare que, contida no elemento
