Java Message Service, ou simplesmente JMS, é uma API Java EE lançada em 1998 pela Sun Microsystems. Aproximadamente 15 anos depois, a API JMS quase não sofreu atualizações em seu projeto inicial, o que é justificado por sua estabilidade e maturidade.

Mas que tipo de serviço é oferecido por esta API? O objetivo principal do JMS é realizar a comunicação entre sistemas através de mensagens. Estas mensagens são produzidas por um JMS Producer, enviadas e armazenadas em um JMS Provider e consumidas por um JMS Consumer. Tais mensagens podem ser armazenadas em um sistema de filas (Queue) ou em um sistema de assinaturas chamado de tópico (Topic), dependendo da necessidade de cada projeto. Outra característica presente no envio de mensagens é a possibilidade delas serem enviadas de maneira síncrona (produtor e consumidor ativos ao mesmo tempo) ou assíncrona (produtor ativo e consumidor desativado). Como as mensagens são armazenadas em um provider, a configuração de seu envio pode ser feita de tal forma que elas fiquem armazenadas no provedor mesmo que o consumidor não esteja sendo executado naquele momento. As mensagens ficariam então armazenadas até que o consumidor fosse ativado e as consumisse. Talvez a principal vantagem deste serviço seja a garantia de que a mensagem será entregue.

Um serviço JMS pode ser usado, por exemplo, como um sistema de chat (bate-papo), como um sistema de confirmação entre serviços ou como um sistema de integração, muito usado para sincronização entre bancos de dados. Pode ser aplicado também para executar tarefas assíncronas em ambientes de cluster, evitando qualquer tipo de duplicação de tarefas que possam vir a ocorrer em consequência das diferentes máquinas virtuais. Alguns sistemas de comércio eletrônico, por sua vez, utilizam mensagens JMS para tratar as operações de compra de um produto pelo consumidor, a análise de crédito deste consumidor junto à operadora de cartão de crédito e também a confirmação de disponibilidade de entrega pela empresa de frete. Os sites destas lojas virtuais apenas apresentam os produtos e recebem os pedidos de compra, enquanto mensagens são geradas com os dados das compras e enviadas para uma ou mais aplicações que processam tais informações de forma externa ao sistema do site. Isso garante ao site um tempo de resposta menor aos acessos, maior segurança e maior volume de transações diárias.

Com base nisso, este artigo abordará os principais conceitos da API JMS, e como exemplo prático, teremos o desenvolvimento de uma aplicação produtora e uma aplicação consumidora de mensagens que se comunicarão com o provider Apache ActiveMQ.


JMS Provider
O JMS Provider é uma aplicação servidora que fornece, além do armazenamento de mensagens, o controle e a administração dos serviços disponibilizados pela tecnologia JMS. O mercado de aplicações JMS é bastante concorrido, tendo inúmeros provedores disponíveis, sendo eles comerciais ou open source. Eles podem ser encontrados de duas formas, no modo chamado standalone como também embutidos em um Java Application Server (Java AS).

Como exemplo de providers standalone temos o Apache ActiveMQ, Joram, HornetQ, OpenJMS, entre outros. Já no modo Java AS temos, por exemplo, no JBoss o HornetQ, no JOnAS o Joram e no Apache Geronimo o ActiveMQ. Servidores como GlassFish, WebSphere e WebLogic também fornecem serviço JMS, o que não acontece com containers web como o Apache Tomcat e o Jetty.

Mesmo quando se usa um Java AS como armazenamento JMS, não existe a necessidade das aplicações, tanto produtoras como consumidoras, estarem armazenadas no Java AS. A comunicação entre aplicação e provedor é realizada por meio de um protocolo de comunicação, de um endereço IP e uma porta de serviço. Essa comunicação não padroniza um único tipo de protocolo de comunicação, como também, não padroniza a porta de serviço. Por conta disso, haverá diferença entre provedores distintos, já que cada um deles define a sua própria configuração de acesso.


Clientes JMS
Existem dois tipos de clientes JMS, a aplicação produtora e a aplicação consumidora. Os clientes consumidores podem consumir mensagens de forma assíncrona ou síncrona, de acordo com a especificação ou necessidade do sistema.

A ...

O Spring, atualmente encontrado na versão estável 3.0.6-RELEASE, é um framework open-source elaborado por Rod Johnson que chegou para ocupar seu espaço no mundo do desenvolvimento Java e não perdê-lo mais. A cada ano os desenvolvedores do Spring apresentam novas ferramentas que tornam mais fácil o seu manuseio e aprimoram ainda mais o framework. O Spring é muito conhecido e utilizado em função do suporte disponível à injeção de dependências, mas oferece apoio a diversas outras tecnologias Java, como JNDI, JMS, JavaMail, Web Service, Persistência de Dados e permite integrá-lo a frameworks como Struts, JSF, ExtJS, DWR, entre outros. A cada nova versão lançada, o Spring acompanha a evolução das tecnologias Java para que elas possam vir a ser integradas a ele. Outra vantagem encontrada no uso do Spring é que ele pode ser usado tanto em aplicações desenvolvidas para Web como para sistemas Desktop, e sua configuração pode ser através de arquivos do tipo XML, anotações ou até mesmo usando-as simultaneamente, conforme seja necessário.

O Hibernate é um projeto open-source fundado por Gavin King e segue os passos do Spring em popularidade, conseguindo se tornar um dos frameworks mais usados para persistência de dados. A ideia deste framework é transformar o acesso a dados, em um banco de dados relacional, mais simples através da manipulação de objetos Java, deixando de lado as instruções SQL empregadas em operações de CRUD. O Hibernate possui uma rica documentação de introdução sobre como usá-lo disponível em vários idiomas, incluindo o Português. Atualmente, ele é encontrado na versão estável 3.6.8-Final, embora já haja a versão 4, ainda não considerada uma versão estável.

Um dos fatores positivos do Spring Framework é a facilidade de integração entre ele e outros frameworks Java, como o próprio Hibernate. Esta é uma parceria de muito sucesso em projetos Java, sendo eles de pequeno, médio ou grande porte. Para realizar esta integração, o Spring fornece algumas alternativas, como a de controle total das transações com o banco de dados através de um objeto do tipo HibernateTemplate, ou uma integração mais passiva, que permite ao desenvolvedor ter um controle maior sobre as classes de persistência, realizando todo o controle necessário.

Neste contexto, neste artigo será apresentada a integração entre os frameworks Spring e Hibernate. Durante os exemplos abordados para a integração dos frameworks, serão levadas em consideração as boas praticas de programação. Sendo assim, dois padrões de projeto serão brevemente apresentados: o Data Access Object (DAO), para organizar as classes de persistência de dados; e o Facade, que divide a aplicação em subsistemas para reduzir a complexidade do código.

Para um melhor proveito do artigo, é importante que o leitor tenha conhecimentos básicos de persistência com o uso do Hibernate e das técnicas de configuração do Spring e injeção de dependências.

CRUD: A sigla tem origem na língua inglesa para Create, Retrieve, Update e Delete. Em português, teria o significado de Criar, Recuperar, Atualizar e Excluir. São as quatro operações básicas em um banco de dados.

Integração entre os frameworks Spring e Hibernate

O Spring fornece algumas formas distintas de realizar sua integração com o Hibernate. É possível, por exemplo, usar o objeto HibernateTemplate e passar o controle total de transação e criação de sessão para o Spring. O desenvolvedor também pode projetar suas próprias classes de persistência para realizar esse controle. Outra possibilidade que o desenvolvedor encontra ao adotar o Spring é no uso da classe que cria a SessionFactory ou EntityManagerFactory. Elas podem ser codificadas por ele próprio, ou então, usar uma das implementações que estão disponíveis entre as bibliotecas do Spring.

Na sequência do artigo, serão demonstradas duas formas de integração entre os frameworks. Primeiramente, será apresentada a implementação das classes de persistência, com transação e sessão controladas no código pelo programador. Para a fábrica de sessões do Hibernate será usada a classe org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean, fornecida pelo Spring. Em resumo, a tradicional classe HibernateUtil, descrita na documentação do Hibernate, e que deveria ser codificada pelo programador, passa a ser desnecessária quando se faz uso da AnnotationSessionFactoryBean.

Ao término da primeira parte, será abordado um novo exemplo de integração. Desta vez com o uso da classe org.springframework.orm.hibernate3.HibernateTemplate, que possibilita ao programador a abstração da criação de sessão e transação, como também a necessidade do controle de quando iniciá-las (open/begin) ou encerrá-las (close).

SessionFactory e EntityManagerFactory: SessionFactory é a fábrica de sessões (Session) do Hibernate. EntityManagerFactory é a fabrica de sessões (EntityManager) do JPA (Java Persistence API). O Hibernate é um framework de persistência e o JPA é uma especificação que padroniza frameworks de persistência. Os desenvolvedores do Hibernate lançaram um projeto chamado Hibernate EntityManager, que é uma camada de compatibilização entre o framework Hibernate e o JPA. Quando se usa a SessionFactory do Hibernate, você tem maiores poderes, pois este supera o JPA em termos de funcionalidades. Quando se usa o EntityManager do JPA, você está tornando sua aplicação portável para outros frameworks de persistência além do Hibernate.

Classes de entidades e mapeamentos

Uma classe de entidade é a representação de uma tabela do banco de dados através de uma classe Java. Já o mapeamento é a forma como o framework de persistência irá se comunicar, ou relacionar, com a tabela no banco de dados. O Hibernate fornece duas formas para realizar o mapeamento: uma por meio de arquivos conhecidos como hbm.xml, que são representações em arquivos XML; ou por anotações, usadas após o lançamento da versão 5 do Java.

Observe que nas classes de entidade, Proprietario (Listagem 1) e Veiculo (Listagem 2), os mapeamentos adotados – para o projeto apresentado no artigo – são indicados por meio de anotações. Estas classes são a representação em Java das tabelas Proprietarios e Veiculos, presentes no banco de dados.

 

package br.com.devmedia.artigo.model;

 

import org.hibernate.annotations.Cascade;

import org.hibernate.annotations.CascadeType;

 

import javax.persistence.*;

import java.io.Serializable;

import java.util.List;

 

@Entity

@Table(name = "PROPRIETARIOS")

public class Proprietario implements Serializable {

...

No mundo do desenvolvimento de sistemas, existem vários frameworks que simplificam a vida dos programadores na implementação de seus projetos. Mas o que é exatamente um framework?

Um framework é uma arquitetura, ou uma estrutura, que fornece ferramentas comuns a vários projetos. Por ser construído com base em diversos tipos de padrões, permite o reuso de classes e proporciona um ambiente de desenvolvimento muito mais produtivo. Neste ponto, vale ressaltar que a solução de problemas comuns no desenvolvimento de softwares pode ser encontrada com muito mais facilidade quando se seleciona um framework específico para tal situação.

Na atualidade, há diversos frameworks disponíveis, como Hibernate, Struts, JSF, Zend, VRaptor, Spring, entre muitos outros. A padronização de processos, o uso de boas práticas, a ampla disponibilidade de recursos, o reaproveitamento de código, a facilidade de manutenção e uma maior produtividade são algumas das vantagens encontradas ao se fazer uso de frameworks em projetos de software.

Um framework muito popular na comunidade Java é o Spring. Idealizado por Rod Johnson, possui código aberto e foi lançado em março de 2004. O Spring é considerado por muitos desenvolvedores como o framework mais vitorioso e poderoso disponível para a linguagem Java, em decorrência de sua grande aceitação, possibilidade de integração e APIs disponíveis. O Spring fornece várias ferramentas para serem utilizadas em projetos, por exemplo: Spring Security, Spring Social, Spring MVC, Spring Rich Client, entre outras. A mais usada com certeza é o Container de Inversão de Controle (Inversion of Control – IoC) e Injeção de Dependências (Dependency Injection – DI). A injeção de dependências possibilita um baixo nível de acoplamento entre os módulos do sistema, e tem como finalidade injetar em cada componente suas dependências. A inversão de controle trás o lema: “não nos chame, nós chamamos você”. É a técnica de desenvolvimento na qual um comportamento do sistema é delegado a uma entidade externa, neste caso o Container IoC do Spring. Isso significa que o Container IoC assume a responsabilidade de criar novos objetos e destruí-los quando necessário.

Além disso, o Spring Framework fornece a implementação de várias especificações Java EE, como: JMS, JDBC, JavaMail, JNDI, entre várias outras. Implementações como estas são disponibilizadas através de objetos que o Spring chama de “template”, como JmsTemplate, HibernateTemplate, RestTemplate, etc. Por exemplo, quem usa o Hibernate necessita programar classes que contenham objetos de SessionFactory, Session e Transaction. Assim, se deve desenvolver o controle de transações e controlar quando iniciar e fechar uma sessão. Com o uso do HibernateTemplate tudo isso é controlado pelo Spring, visto que ele já possui tudo isso implementado. Mesmo assim, se você precisar usar a sua própria implementação, também pode ter essa possibilidade de integrá-la com o Spring.

Neste contexto, este artigo apresentará alguns conceitos e técnicas de como fazer uso da injeção de dependências gerenciada pelo Spring, e como utilizar e configurar um objeto JdbcTemplate para persistência de dados. Será demonstrado também um caso de testes usando o framework JUnit, integrado com o Spring, para testar a injeção de dependências e a persistência de dados. O artigo aborda ainda uma pequena introdução ao uso da linguagem SpEL (Spring Expression Language), que possui vários recursos como a leitura de arquivos de propriedades.

O que é o framework Spring?

O Spring, atualmente na versão 3, nasceu como uma resposta à complexidade existente no uso de EJB (Enterprise Java Beans). Rod Johnson idealizou e o descreveu em seu livro “Expert One-on-One: J2EE Design and Development”. O framework é baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência (DI). No Spring, o Container IoC se encarrega de “instanciar” classes de uma aplicação Java e definir as dependências entre elas através de um arquivo de configuração no formato XML ou anotações nas classes, métodos e propriedades. Desta forma, se permite o baixo acoplamento entre classes de uma aplicação orientada a objetos.

Este framework é composto por recursos organizados em vários módulos (veja a Figura 1), como testes unitários, web, persistência, acesso remoto, programação orientada a aspectos, entre outros. Estes módulos podem ser implementados separadamente ou em conjunto, conforme a necessidade do projeto. Isto possibilita que o Spring seja empregado nos mais variados tipos de aplicação, sendo elas de pequeno, médio ou grande porte. Com sua arquitetura baseada em interfaces e POJOs, possui como um dos seus principais objetivos tornar mais fácil o uso das tecnologias existentes no mercado. Outro recurso interessante é o Lazy Initialization, que permite ao Spring carregar apenas os beans solicitados. Assim, a aplicação ganha em desempenho porque se um bean for declarado no contexto, mas não estiver sendo utilizado, ele não será carregado até que seja necessário. Para entender um pouco mais sobre o funcionamento do Spring Framework, é interessante analisar a distribuição de seus módulos e sub módulos descritos a seguir.

Plain Old Java Objects, ou simplesmente POJO, são objetos que não herdam ou implementam ninguém. Eles são independentes de classes externas, ou seja, são classes simples, que não estão presas a nenhum framework ou biblioteca. O termo foi criado quando Rebecca Parsons, Josh MacKenzie e Martin Fowler se preparavam para uma palestra em uma conferência em Setembro de 2000.

Módulo Core Container

O módulo Core Container é chamado de Container de Inversão de Controle e é considerado o núcleo do framework. Nele estão localizadas as funcionalidades padrões do Spring e alguns módulos internos como o Core, Beans, Context e Expression Language. O Beans e o Core fornecem as peças fundamentais da estrutura, incluindo o IoC (Inversão de Controle) e o DI (Injeção de Dependência).

O BeanFactory, presente no módulo Beans, é uma implementação sofisticada do padrão Factory, sendo responsável por aplicar a injeção de dependências e a inversão de controle no sistema.

O Context se constitui por uma base sólida fornecida pelos módulos Core e Beans. É um meio para acessar objetos de maneira semelhante a um registro JNDI. Ele herda as características do módulo Beans e adiciona suporte à internacionalização (i18N) a partir de arquivos de mensagens, comunicação entre os componentes via propagação de eventos, recurso de carregamento de arquivos e a criação de contextos específicos, tais como para aplicações desktop ou aplicações web. O módulo também suporta recursos Java EE, como EJB, JMX, JNDI, Mail, entre outros. O ponto principal do Context é a interface ApplicationContext, uma extensão da interface BeanFactory.

O módulo Expression Language fornece uma linguagem de expressão poderosa para consultar e manipular objetos em tempo de execução. Esta é uma versão “turbinada” da Unified EL usada no Java EE 5 para padronizar as linguagens de expressão presentes nas tecnologias JSP e JSF. A linguagem suporta configurar, obter e atribuir o valor de uma propriedade, invocar um método, acessar coleções (arrays, lists, maps), indexadores lógicos, operadores aritméticos, entre outras coisas.

O padrão de projeto Factory fornece uma interface para a criação de famílias de objetos correlatos ou dependentes sem a necessidade de especificar a classe concreta destes objetos. Seu uso é útil quando você precisa criar objetos dinamicamente sem conhecer a classe de implementação, somente sua interface. O padrão Factory estabelece uma forma de desenvolver objetos que são responsáveis pela criação de outros objetos.

Módulo Data Access/Integration

O módulo Data Access/Integration é formado pelos módulos internos JDBC, ORM, OXM, JMS e Transactions. O JDBC, por exemplo, fornece uma camada de abstração para acesso JDBC que anula a necessidade de fazer a codificação da classe de conexão com o banco de dados. O módulo ORM dispõe das camadas de integração para APIs de mapeamento objeto-relacional, incluindo JPA, JDO, Hibernate e iBatis. O módulo OXM fornece uma camada de abstração que suporta implementações de mapeamento Objeto/XML para JAXB, Castor, XMLBeans, JiBX e XStream. O módulo Java Message Service (JMS) contém recursos para produzir e consumir mensagens por modo de filas ou tópicos. O módulo de transação (Transactions), por fim, suporta o gerenciamento de tr

...

  Em meados da década de 70 o Engenheiro Civil Christopher Alexander documentou os padrões mais utilizados no ramo da Engenharia Civil, e este feito o fez ser considerado o inventor dos padrões de projeto (Design Patterns). Tempos depois a área da informática adotou tal técnica e termo, e assim, deu início aos seus próprios padrões de projeto. Alguns desses padrões já são bastante conhecidos, como: o DAO, utilizado para separar as regras de persistência de dados das classes de negócios; o MVC, que possui a finalidade de dividir as tarefas dentro da aplicação, criando um baixo acoplamento e uma alta coesão das classes; entre vários outros.

Entre esses padrões, existe um denominado Observer. Este padrão define a dependência um-para-muitos entre objetos. Dessa forma, quando um objeto mudar seu estado, todos os seus dependentes serão avisados e atualizados automaticamente. O processo funciona mais ou menos da seguinte maneira: uma classe é marcada como observada e outras classes são marcadas como observadoras. Quando o objeto observado sofre uma alteração, ele envia uma mensagem do tipo “fui modificado” para seus observadores e estes são atualizados para o estado atual com tais alterações. A implementação do Padrão Observer pode ser realizada de duas formas distintas, uma sendo toda ela desenvolvida pelo programador, e a outra utilizando a própria implementação disponível nas classes do JDK, especificamente no pacote java.util.

Outro ponto que será abordado no artigo é a união entre padrões de projeto. Para isso, vamos demonstrar como desenvolver um projeto que utilize ao mesmo tempo os padrões Observer e MVC.

O uso de um padrão de projeto tem como princípio organizar e facilitar o desenvolvimento de sistemas. O Observer é um padrão que serve para manter o estado dos objetos sempre atualizados e pode, inclusive, ser adotado em conjunto com o padrão MVC.

 

Definindo o Padrão Observer

Como saber quando usar o padrão Observer? Essa é uma dúvida recorrente não somente para o padrão Observer, mas para qualquer outro padrão de projeto. Para saber quando usar um padrão específico é necessário conhecer o problema que deve ser resolvido e então buscar um padrão que possa solucioná-lo. O Observer pode ser usado quando existe no projeto a necessidade de fazer com que um conjunto de objetos seja notificado e atualizado automaticamente após um determinado evento no sistema. Este conjunto de objetos, que pode pertencer a classes distintas, observa e é notificado quando o estado de um outro objeto, que seja comum a eles, é alterado.

Este padrão de projeto utiliza basicamente duas classes: a que será observada (Subject ou Observable) e a observadora (Observer). As classes observadoras devem implementar uma interface específica, já a classe que será observada implementa uma interface ou estende uma superclasse.

A vantagem encontrada neste padrão é que tanto os observadores quanto os sujeitos (observados) podem ser reutilizados, já que existe um baixo acoplamento entre eles, devido ao uso de interfaces e classes abstratas, o que é um bom princípio de design. Com isso, é possível aumentar o número de observadores sem precisar modificar a classe observada. O observador pode ser implementado de forma que, quando receber uma notificação de mudança de estado do objeto observado, ele tenha autonomia em considerá-la ou ignorá-la.

A desvantagem é que usar este padrão de forma indiscriminada pode causar sério impacto na performance do sistema. Quando todos notificam todos a cada mudança, o sistema acaba ficando inundado de requisições, o que poderá levar a um desempenho mais lento.

Métodos que definem o padrão

O Observer é formado por métodos que possuem padrões de nomenclatura e comportamentos específicos. É importante seguir estes padrões para que implementações diferentes do Observer possam ser facilmente identificadas por desenvolvedores que não as codificaram. Os métodos listados a seguir estão presentes na implementação nativa do JDK:

·         addObserver(Observer o) – adiciona o observador, recebido como parâmetro, a uma lista de observadores que devem implementar a Interface Observer;

·         removeObserver(Observer o) – remove o objeto observador, recebido como parâmetro, da lista de observadores;

·         hasChanget() – retorna true quando o método setChange() é invocado, e false quando o método clearChange() for invocado;

·         setChange() – este método é invocado quando o objeto for modificado, alertando o método hasChanged() a retornar true;

·         clearChange() – sua função é alertar que as alterações já foram realizadas e então o método hasChanged() passa a retornar false. Geralmente esse método é invocado por notifyObservers() após este realizar sua função;

...

Conforme o dicionário Aurélio, “certificado” tem a seguinte definição: “Dar como certo; assegurar como verdadeiro. Convencer da certeza. Fazer (alguém) ciente de. Passar certidão de.”. Tal definição pode ser vista como um sinônimo para a certificação Java, considerada uma prova que, em tese, garante que o profissional possui conhecimento do assunto tratado e esteja habilitado a trabalhar com ele. Já no portal da Oracle é possível encontrar a seguinte afirmação: “Obter uma certificação na tecnologia Java da Oracle representa uma comprovação evidente de suas habilidades técnicas, dedicação profissional e motivação, o que pode lhe trazer vantagens no mercado de trabalho. Amplamente reconhecidas no setor, as opções de treinamento e certificação na tecnologia Java da Oracle ajudam a comprovar que você possui as habilidades necessárias para cumprir com eficiência os desafios de uma empresa de TI.”

O mercado de trabalho possui demanda por profissionais com conhecimento e experiência em Java e as certificações são cada vez mais valorizadas e consideradas por muitos como um fator importante para o sucesso na carreira. Porém obter uma certificação Java pode ser para alguns um objetivo muito trabalhoso. A experiência no uso da linguagem muitas vezes não se faz suficiente para a aprovação no exame. Essa experiência deve ser complementada com muita dedicação aos estudos através de bons livros, simulados e muita codificação.

Para os jovens programadores que estão iniciando no mundo da programação Java e não possuem experiência profissional, é bastante válido possuir uma certificação. A certificação não substitui o conhecimento adquirido no mercado de trabalho, mas insinua ao empregador que este jovem sabe estudar, se preparar para desafios e que tem o conhecimento da linguagem. Para o iniciante em Java, o estudo limitado a livros pode não ser suficiente para passar no exame, então é aconselhável procurar um bom curso de Java que tenha como opção um módulo preparatório para a certificação desejada.

A Sun Microsystems, antiga detentora dos direitos sobre o Java, oferecia oito certificações quando foi adquirida pela Oracle e esse número foi aumentado para doze. Cada certificação possui um objetivo muito bem definido e são divididas pela Oracle por categorias como Associado, Profissional, Máster e Especialista. Além das categorias as certificações possuem o Job Role, um tipo de cargo que faz referência ao membro certificado como sendo um Associado, Programador, Desenvolvedor ou Arquiteto. Existem certificações voltadas para as áreas de desenvolvimento Java SE (Figura 1), Java EE (Figura 2) e Java ME (Figura 3). Outra característica das certificações são as versões disponibilizadas para o exame. Cada certificação faz referência a uma versão específica do Java, por exemplo, Java 1.4, Java 5 ou Java 6. Se o candidato ao exame da certificação OCPJP 6 (antiga SCJP 6) estudou ou tem experiência apenas com o Java 1.4, verá na prova muitos conceitos desconhecidos, o que pode ser o fator relevante para sua reprovação. Outro ponto importante a ser observado pelo candidato é o idioma em que o exame será aplicado. Algumas certificações possuem versões em vários idiomas, entre eles o Português, mas na maioria delas apenas está disponível o idioma Inglês. Lembre-se que realizar uma prova com sessenta ou mais questões, em um idioma que você não tem domínio, também pode acabar sendo um fator propício à reprovação.

As certificações Oracle Java, bem como na época da Sun, possuem uma restrição de dependência entre elas. Algumas certificações dependem que você já tenha sido aprovado no exame de outra certificação específica, ou seja, não é possível prestar exame para a certificação de desenvolvedor web (OCPJWCD) sem possuir a certificação de programador (OCPJP), por exemplo.

As Categorias das Certificações Oracle

A Oracle divide as certificações Java em quatro categorias ou credenciais, que condizem com o grau de habilidade e conhecimento do indivíduo em relação à tecnologia Java. Veja na Figura 4 a categoria referente a cada certificação mais o Job Role de cada uma delas.

Oracle Certified Associate

A Oracle Certified Associate (OCA) é normalmente o primeiro passo para alcançar o carro-chefe das certificações, a Oracle Certified Professional. A credencial OCA garante que o indivíduo é conhecedor dos fundamentos da tecnologia.

Oracle Certified Professional

A Oracle Certified Professional (OCP) é a referência de habilidade profissional e conhecimentos técnicos necessários para gerir, desenvolver ou implementar em toda a empresa bases de dados, middleware, ou aplicações. Cada vez mais os gerentes de TI usam a credencial OCP para avaliar as qualificações dos funcionários e candidatos a emprego.

Oracle Certified Master

O Oracle Certified Master (OCM) reconhece o nível mais recente e avançado das habilidades do indivíduo comprovando sua capacidade de conhecimento. Esses profissionais são qualificados para responder às perguntas mais difíceis e resolver os problemas mais complexos.

Oracle Certified Expert Program

O programa Oracle Certified Expert (OCE) é uma parte do Programa de Certificação da Oracle que concede credenciais que reconhecem a competência em tecnologias específicas, arquiteturas ou domínios atualmente não abrangidos no caminho baseado nas Certified Associate e Certified Professional.

Como já citado neste artigo, o programa de certificação Java da Oracle atualmente possui doze (12) certificações. Os exames estão divididos em três plataformas, o Java Standard Edition (Java SE), o Java Enterprise Edition (Java EE) e o Java Micro Edition (Java ME) – veja a Figura 4. Como pode ser observado, além das avaliações tradicionais, a Oracle definiu algumas novas certificações que não existiam no programa oficial da Sun, como é o caso das certificações específicas para JPA, JSF e EJB.

Oracle Certified Associate, Java SE5/SE 6

A Oracle Certified Associate, Java SE5/SE6 é a entrada ideal para o desenvolvimento de aplicativos ou um software de gerenciamento de projetos utilizando tecnologias Java. Essa credencial valida mundialmente os conhecimentos básicos sobre conceitos orientados a objetos, UML, a linguagem de programação Java, e conhecimentos gerais sobre plataformas e tecnologias Java. O perfil do candidato para este exame inclui: programadores Java de nível inicial, alunos estudando para se tornar programadores Java e gerentes de projeto com tecnologia Java na indústria de desenvolvimento de software. Não há a necessidade de o candidato possuir qualquer outra certificação para prestar o exame.

Veja a seguir alguns detalhes sobre o exame desta certificação:

...

Java é uma das linguagens mais usadas na programação de aplicações web, e para garantir a qualidade dessas aplicações existem boas práticas que podem ser aplicadas durante seu desenvolvimento. O uso de padrões de projeto é um bom exemplo de boas práticas que pode ser utilizado, possibilitando benefícios como melhorar a organização do código, facilitar a manutenção, reutilização, entre várias outras.

O padrão MVC é adotado na grande maioria dos sistemas desenvolvidos para web, e possibilita a separação do projeto em camadas muito bem definidas, proporcionando assim, uma divisão de tarefas bem específicas entre os desenvolvedores. Assim, um programador pode trabalhar em suas tarefas enquanto o web designer desenvolve a interface gráfica. É possível também desenvolver várias interfaces gráficas para uma mesma lógica de negócios, já que a comunicação entre a visualização e a lógica é realizada por um intermediador conhecido como controlador.

No primeiro artigo da série aprendemos sobre os conceitos, características e porque o uso de Padrões de Projeto é considerado uma boa prática no desenvolvimento de softwares. Estudamos brevemente alguns conceitos ligados ao padrão Data Access Object (DAO) e como utilizá-lo em conjunto com o padrão Model-View-Controller (MVC), foco principal do estudo. Por último, criamos uma pequena aplicação financeira para ambientes desktop utilizando os conceitos citados no artigo.

Nesta segunda parte, o artigo mantém o foco na criação de um sistema usando o padrão MVC. Este sistema será desenvolvido na plataforma web com o uso de Servlet na camada controladora e páginas JSP na camada de visualização. Já com a camada de modelo será demonstrado como reutilizá-la a partir da aplicação desktop no projeto web, o que proporciona um tempo de desenvolvimento menor para o programador. A reutilização desta camada será proporcionada pela criação de uma biblioteca Java em um arquivo do tipo JAR.

Por fim, vamos apresentar uma breve descrição sobre frameworks web que auxiliam os desenvolvedores na criação de aplicações com o uso do padrão MVC.

Sistema web utilizando o padrão MVC

Na primeira parte do artigo desenvolvemos uma aplicação financeira na plataforma desktop (Swing) que tinha como objetivo o cálculo de juros simples e juros compostos utilizando o padrão de projeto MVC. Nesta segunda parte, o artigo irá demonstrar como aplicar os conceitos do padrão MVC em uma aplicação financeira, desta vez na plataforma web. Vamos analisar como tratar cada uma das três camadas do padrão MVC e apresentar que diferenças podem ser encontradas, na camada de visão e na camada de controle, quando um projeto desktop é reestruturado para o ambiente web.

Camada Model (modelo)

No projeto da aplicação desktop a camada model foi desenvolvida no pacote ejm.appdesktop.model. Esta camada é responsável pela lógica de negócios da aplicação, sendo constituída pelos pacotes ejm.appdesktop.model.entity (classes de entidades), ejm.appdesktop.model.dao (classes de acesso a banco de dados) e ejm.appdesktop.model.service (classe com as regras de negócio). Veja mais sobre estes pacotes no artigo anterior.

Como o projeto web terá o mesmo objetivo do projeto desktop (aplicação financeira), vamos reaproveitar as classes da camada model. Isto é possível porque as classes do modelo não possuem nenhum tipo de dependência com a camada de visualização (interface gráfica) e também não são dependentes do controlador. É o controlador que deve se adequar ao modelo e não o contrário. Deste modo os programadores têm um ganho significativo no tempo de desenvolvimento da nova aplicação, já que a camada de modelo está pronta e não precisa ser codificada novamente.

A maneira apropriada para reutilizar classes Java é através do uso de bibliotecas. Uma biblioteca não é nada mais

...

Em Java, todas as classes, incluindo classes abstratas, necessitam pelo menos de um construtor. Através do construtor o desenvolvedor terá acesso à classe, às suas variáveis e métodos. Os construtores sempre serão chamados em tempo de execução e disponibilizarão a criação de um objeto desta classe.

Embora pareça, um construtor não é igual a um método e possui características próprias, mas à primeira vista, para iniciantes na linguagem Java, essas características se tornam muitas vezes imperceptíveis. A má utilização dos construtores pode render erros em tempo de compilação como até exceções em tempo de execução.

Deste modo, veremos neste artigo como criar um construtor, suas principais características e suas regras de execução. Vamos aprender sobre a especificação JavaBean e por que segui-la é tão importante. Ademais, analisaremos mais algumas características básicas que definem a implementação de um construtor para a linguagem Java.

Características básicas de um construtor

JavaBean é uma especificação criada para que desenvolvedores, quando criarem seus códigos, sigam um padrão de implementação e de empacotamento. Deste modo, conhecer alguns itens desta especificação nos favorece muito, por exemplo, para reconhecer a diferença entre um construtor e um método.

Empacotamento é uma convenção sugerida pela Sun para organização das classes em pacotes específicos. Os pacotes podem evitar os conflitos de classes de mesmo nome e organizá-las da melhor forma para serem reutilizadas. A sugestão diz que devemos iniciar os pacotes com o nome do domínio invertido, como “br.com.devmedia” e na sequência um pacote com o nome do projeto e então seus demais pacotes.

O padrão JavaBean diz que toda classe deve começar com letra maiúscula e as demais letras devem ser em minúsculas, como por exemplo: public class First {...}. Quando o nome da classe for um nome composto, a primeira letra de cada palavra deverá ser em letra maiúscula seguida de letras minúsculas e sem espaços ou qualquer outro caractere entre os nomes, como por exemplo: public class MyFisrtClass {...}.

Quando criamos um método em Java, o mesmo também deve seguir um destes padrões. A diferença no nome de um método para o nome de uma classe é que o nome do método inicia com a primeira letra em minúscula e assim todas as demais, como por exemplo: find(). Quando temos um método com nome composto, teremos a primeira letra do primeiro nome com letra minúscula e a primeira letra dos demais nomes em maiúscula, e todas as demais letras em minúsculo, como no exemplo: findByNome().

Uma regra importante sobre a criação de um método, é que todo método deve ter um tipo de retorno, seja ele um tipo primitivo, um objeto ou apenas o tipo void.

Utilizando estas regras citadas anteriormente, poderemos reconhecer um construtor facilmente. Um construtor tem suas próprias regras e por isso as dicas anteriores são inicialmente tão importantes. Veja bem, enquanto o nome de um método inicia com letra minúscula, um construtor deve sempre ter o seu nome idêntico ao nome da classe, assim, ele sempre iniciará com letra maiúscula. Outra observação importante é que um método sempre terá um tipo de retorno, porém, um construtor jamais terá um tipo de retorno.

Vejamos mais algumas características:

·         Um construtor pode ter qualquer tipo de modificador de acesso, seja ele private, public, protected ou mesmo default;

·         Se você não criar um construtor em sua classe, um construtor padrão será criado pelo compilador de forma implícita;

·         Um construtor padrão será sempre um construtor sem argumentos;

·         Quando você criar um construtor com argumentos, o compilador não irá criar o construtor padrão, isso depende de você;

·         Todo construtor deve ter como primeira instrução uma chamada a super(), que será gerada implicitamente pelo compilador ou explicitamente por você, ou então uma chamada explícita a this().

Criando Construtores

Vamos agora aprender a criar construtores em uma classe e entender quais são as regras de execução deles. É muito importante que o desenvolvedor entenda como a execução de um código irá funcionar através da criação de um ou mais construtores na classe e também a relação existente entre construtores da superclasse com construtores de suas subclasses. Você deve ter sempre em mente que toda classe em Java deve ter pelo menos um método construtor, por isso é tão importante entender como eles funcionam.

Classe com construtor implícito

Chamamos de explícito um construtor que seja declarado pelo desenvolvedor, ou seja, esteja visível no código fonte. Quando este não está visível no código fonte, o chamamos de implícito e neste caso será criado pelo compilador. Na Listagem 1, o construtor não será criado, assim, o compilador irá gerá-lo implicitamente.

 

package javamagazine.listagem1;

 

public class Animal {

    private double peso;

    private String grupo;

    // gerar getters e setters

    public static void main(String[] args) {

        Animal animal = new Animal();

        animal.setPeso(5.5);

        animal.setGrupo("Mamiferos");

        System.out.println("Peso: " + animal.getPeso() + " Grupo: " + animal.getGrupo());

    }

}

 

O que aconteceu na Listagem 1?

Primeiro criamos uma classe chamada Animal, e em seguida duas variáveis de instância, peso e grupo. No método main() foi declarada uma variável de referência chamada animal, do tipo Animal e atribuído a ela um objeto do tipo Animal. Quando utilizamos o comando new Animal(), “mandamos” construir este objeto e atribui-lo à variável de referência. Teremos então acesso a todos os métodos e variáveis da classe Animal, através da variável animal.

Mesmo sem declarar um construtor explicitamente, esse código não gera nenhum erro de compilação ou de execução, por que como já foi dito, o compilador irá se encarregar de criá-lo.

Classe com construtor explícito

Se quiséssemos declarar outro construtor, que possuísse como argumento um valor correspondente a peso e outro correspondente a grupo, conforme a Listagem 2, precisaríamos então obrigatoriamente declarar o construtor padrão se quiséssemos utilizá-lo, senão, ocorreria um erro de compilação referente à linha que possui a instrução new Animal().

Sempre que um construtor com argumentos for declarado, o compilador deixará de criar o construtor padrão, então devemos criá-lo explicitamente caso seja preciso utilizá-lo.

 

package javamagazine.listagem2;

 

public class Animal {

    private double peso;

    private String grupo;

    //gerar getters and setters

 

    public Animal() {

    //padrão

    }

 

    public Animal(double peso, String grupo) {

        super();

        this.peso = peso;

        this.grupo = grupo;

    }

 

    public static void main(String[] args) {

        Animal a = new Animal();

        a.setPeso(5.5);

        a.setGrupo("Mamiferos");

        System.out.println("Peso: " + a.getPeso() + " Grupo: " + a.getGrupo());

        Animal b = new Animal(6.0, "Aves");

        System.out.println("Peso: " + b.getPeso() + " Grupo: " + b.getGrupo());

    }

}

 

Na Listagem 2, foram declarados dois construtores. O primeiro deles, com o comentário “padrão”, possibilita criar o objeto a e o segundo o objeto b. O segundo construtor, com a lista de argumentos, nos permite criar um objeto e atribuir a este valores em tempo de criação, sem precisar utilizar o método set(), referente a cada variável de instância, como foi feito na utilização do construtor padrão.

A chamada a super() é um padrão implícito em qualquer construtor. Não precisa ser feita. No entanto, caso seja utilizada, ela deve ser a primeira instrução dentro do construtor. Veja que na Listagem 2 o construtor padrão não possui uma chamada a super(), porém esta chamada será feita implicitamente pelo compilador. Já no construtor com argumentos foi utilizada explicitamente a chamada a super(), e ela é a primeira instrução no código. Se essa chamada a super() fosse feita como segunda ou terceira instrução, ocorreria um erro de compilação com uma mensagem parecida com esta: call to super must be first statement in constructor.

Nós podemos criar quantos construtores quisermos em uma classe, desde que, é claro, sejam obedecidas as regras de sobrecarga.

 

Sobrecarga: Recurso disponível em Java que permite a existência de vários métodos com o mesmo nome, desde que sejam criados com uma lista de argumentos diferentes.

 

Classe com construtor explícito usando this()

Podemos também, por exemplo, fazer uma chamada ao construtor padrão a partir do construtor sobrecarregado, como na Listagem 3.

Esta execução irá chamar o construtor com argumentos e executará o this(), assim, será feita uma chamada automática ao construtor padrão e será impresso no console a seguinte frase “Construtor Padrão”. Então a execução voltará para o construtor com os argumentos e executará as linhas restantes inserindo na variável peso e na variável grupo os valores passados como parâmetros na lista de argumentos. Quando todas as linhas do construtor forem executadas, a próxima linha no método main() será executada e será impresso no console o valor de peso e o valor de grupo.

É impossível ter no mesmo construtor uma chamada a super() e uma chamada a this(). Se isso ocorrer, será gerado um erro em tempo de compilação. Caso seja utilizado o super() antes do this(), uma mensagem de erro como esta será exibida pelo compilador: call to this must be first statement in constructor. Se o this() vier antes do super(), então a mensagem será como esta: call to super must be first statement in constructor. Veja que ambas as mensagens sempre informam que a segunda declaração deve ser a primeira chamada no construtor, por esse motivo não é permitida a utilização de ambos no mesmo construtor.

O this() sempre fará uma chamada ao construtor da própria classe, enquanto o super() fará a chamada ao construtor da superclasse.

 

package javamagazine.listagem3;

 

public class Animal {

    private double peso;

    private String grupo;

    //gerar getters and setters

 

    public Animal() {

        System.out.println("Construtor Padrão");

    }

 

    public Animal(double peso, String grupo) {

        this();

        this.peso = peso;

        this.grupo = grupo;

    }

 

    public static void main(String[] args) {

        Animal b = new Animal(6.0, "Aves");

        System.out.println("Peso: " + b.getPeso() + " Grupo: " + b.getGrupo());       

    }

}

 

Poderíamos também fazer uso do this(), passando por ele uma lista de argumentos que faria uma chamada a um construtor respectivo da classe, veja na Listagem 4.

Nesta listagem, a execução do método main() fará uma chamada ao construtor padrão que através do this(6.0, “Aves”), faz uma chamada ao construtor sobrecarregado. Será impresso no console a frase “Construtor Sobrecarregado” e o valor da variável peso e da variável grupo serão inseridos pelos parâmetros enviados pela lista de argumentos. Por fim, a execução voltará ao método main() e será impresso no console os valores de peso e grupo.

 

package javamagazine.listagem4;

 

public class Animal {

    private double peso;

    private String grupo;

    //gerar getters and setters

 

    public Animal() {

        this(6.0, "Aves");

    }

 

    public Animal(double peso, String grupo) {

        System.out.println("Construtor Sobrecarregado");

        this.peso = peso;

        this.grupo = grupo;

    }

 

    public static void main(String[] args) {

        Animal b = new Animal();

        System.out.println("Peso: " + b.getPeso() + " Grupo: " + b.getGrupo());

    }

}

Utilizando Herança

Já vimos que quando um construtor faz uma chamada a this(), está apenas invocando outro construtor da mesma classe. Mas para que serve então uma chamada a super()?

Toda classe em Java é uma herança da classe Object, ou seja, é uma classe filha de Object. Assim, quando super() é invocado, o que ele faz é uma chamada ao construtor da sua superclasse.

Quando trabalhamos com herança em Java, usamos a palavra chave extends para referenciar qual classe será herdada, porém isto está implícito em todas as classes filhas da classe Object. Sempre que uma subclasse é instanciada, seu construtor é invocado e a primeira execução dentro deste é uma chamada a super(), que invoca o construtor de sua superclasse. A superclasse por sua vez também invoca o construtor de sua superclasse, se ela for subclasse, caso contrário o construtor da classe Object.

 

Herança: Herança é o recurso na programação orientada a objetos que permite que classes compartilhem variáves e métodos de uma superclasse, assim, permite o reaproveitamento de código.

 

Construtores quando utilizamos herança

Vejamos o seguinte cenário na Tabela 1. Temos uma classe Dog que é uma herança da classe Animal que por sua vez é uma classe filha da classe Object.

 

4. public Object() { }

...

O Engenheiro Civil Christopher Alexander criou o que se considera o primeiro padrão de projeto em meados da década de 70. É considerado um padrão de projeto uma solução já testada e documentada que possa resolver um problema específico em projetos distintos. Através do trabalho de Alexander, profissionais da área de desenvolvimento de software utilizaram tais conceitos para iniciar as primeiras documentações de padrões de projetos, tornando-as acessíveis para toda a área de desenvolvimento.

O então funcionário da corporação Xerox PARC, Trygve Reenskaug, iniciou em 1979 o que viria a ser o nascimento do padrão de projeto MVC. A implementação original foi descrita no artigo “Applications Programming in Smalltalk-80: How to use Model-View-Controller”. A ideia de Reenskaug gerou um padrão de arquitetura de aplicação cujo objetivo é separar o projeto em três camadas independentes, que são o modelo, a visão e o controlador. Essa separação de camadas ajuda na redução de acoplamento e promove o aumento de coesão nas classes do projeto. Assim, quando o modelo MVC é utilizado, pode facilitar em muito a manutenção do código e sua reutilização em outros projetos.

Neste contexto, este artigo apresentará conceitos para a utilização do padrão de projeto Model-View-Controller (MVC), suas características e vantagens de uso. Também demonstrará dois pequenos exemplos de projetos utilizando o padrão MVC, um desktop e outro web. Além disso, fará uma rápida abordagem sobre o que é um Framework e quais deles podem auxiliar o programador na utilização dos conceitos MVC em projetos Web. O padrão DAO terá uma rápida abordagem no artigo, sendo demonstrado em qual camada ele deve ser aplicado quando usado em conjunto com o modelo MVC. Ademais, algumas vantagens serão abordadas quando se utiliza um ou mais padrões de projeto em desenvolvimento de software e porque isto se torna uma boa prática.

Acoplamento: é o grau em que uma classe conhece a outra. Se o conhecimento da classe A sobre a classe B for através de sua interface, temos um baixo acoplamento, e isso é bom. Por outro lado, se a classe A depende de membros da classe B que não fazem parte da interface de B, então temos um alto acoplamento, o que é ruim.

Coesão: quando temos uma classe elaborada de forma que tenha um único e bem focado propósito, dizemos que ela tem uma alta coesão, e isso é bom. Quando temos uma classe com propósitos que não pertencem apenas a ela, temos uma baixa coesão, o que é ruim.

Padrão de Projeto

Alexander descreveu um padrão como sendo um problema que se repete inúmeras vezes em um mesmo contexto e que contenha uma solução para resolver tal problema de modo que esta solução possa ser utilizada em diversas situações. O termo padrões de projeto ou Design Patterns, descreve soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. O Factory é um destes padrões. Ele é baseado em uma interface para criar objetos e deixar que suas subclasses decidam que classe instanciar. Deste modo, utilizasse o conceito de fábrica de objetos quando um objeto é utilizado para a criação de outros objetos. Algo assim foi implementado no Framework Hibernate para a criação de uma espécie de fábrica de sessões, ou seja, na criação de uma única SessionFactory teríamos acesso a vários objetos do tipo Session.

Padrões de projeto são estabelecidos por um nome, problema, solução e consequências. O nome deve ser responsável por descrever o problema, a solução e as consequências. Quando alguém na equipe de um projeto se refere a um padrão pelo nome, os demais membros da equipe devem relacionar este nome com um problema encontrado, a solução e as consequências na utilização de tal padrão. Encontrar um nome para um novo padrão é considerada uma etapa difícil, já que o nome deve proporcionar a ideia para a qual o padrão foi criado. O problema descreve quando devemos aplicar o padrão, qual o problema a que se refere e seu contexto. A solução descreve os elementos que fazem parte da implementação, as relações entre os elementos, suas responsabilidades e colaborações. Uma solução não deve descrever uma implementação concreta em particular e sim proporcionar uma descrição abstrata de um problema e como resolvê-lo. As consequências são os resultados, vantagens e desvantagens ao utilizar o padrão. São importantes para avaliar as alternativas descritas bem como proporcionar uma ideia de custos e benefícios ao aplicá-lo.

Um exemplo existente e muito utilizado de padrão é o Data Access Object, ou simplesmente DAO. Foi uma solução encontrada para resolver problemas referentes à separação das classes de acesso a banco de dados das classes responsáveis pelas regras de negócio. Já o conceito principal do modelo MVC é utilizar uma solução já definida para separar partes distintas do projeto reduzindo suas dependências ao máximo.

Desenvolver uma aplicação utilizando algum padrão de projeto pode trazer alguns dos seguintes benefícios:

·         Aumento de produtividade;

·

...

Na linguagem Java há dois tipos de membros que podem ser utilizados em uma classe, os membros estáticos e os membros de instância. Estes tipos de membros apresentam diferenças na forma como devem ser declarados e também na maneira como se comportam em uma classe.

Os membros de uma classe podem ser considerados como métodos, variáveis e blocos estáticos ou de instância. Os membros estáticos sempre devem ser marcados com a palavra chave static, enquanto os membros de instância não devem possuir esta marcação.

Neste artigo analisaremos as principais diferenças existentes entres métodos, variáveis e blocos de instância e estáticos. Analisaremos também como usar cada um deles, e qual o comportamento que eles terão na execução de uma classe e também quando trabalhamos com herança. Exemplos práticos serão demonstrados e seus resultados serão descritos passo a passo para melhor compreensão do assunto. Além disso, faremos uma pequena abordagem sobre os conceitos e regras de polimorfismo e de como sobrescrever e sobrecarregar métodos.

Membros Estáticos

A linguagem Java nos permite ter variáveis, blocos e métodos do tipo static. A palavra static está entre algumas das palavras chaves do Java, ou seja, faz parte das palavras reservadas que não podem ser usadas como nome de variáveis, métodos ou classes. Uma variável, um bloco ou mesmo um método do tipo static, não faz parte da instância de uma classe e sim da classe. Quando criamos uma classe com membros estáticos, esses membros serão os primeiros códigos a serem carregados, mesmo que não haja nenhuma instância desta classe.

O método estático mais conhecido é sem dúvida nenhuma o main(), utilizado para inicializar uma aplicação desenvolvida em Java. Dentro de um método ou de um bloco de inicialização estático, só podemos acessar variáveis ou outros métodos estáticos, e para acessarmos membros não estáticos precisamos então criar uma instância da classe.

Quando criamos variáveis e blocos estáticos em uma classe, devemos saber que eles serão executados de cima para baixo, ou melhor, do primeiro para o último criado. Podemos também ter uma classe apenas com membros estáticos.

Uma observação importante é que um método estático nunca será sobrescrito na subclasse. O conceito de sobrescrever não existe para métodos estáticos, ele serão redefinidos.

Devemos saber o que se pode e o que não se pode marcar como um membro estático. A linguagem Java oferece as seguintes possibilidades para esta marcação:

·         Blocos de inicialização;

·         Variáveis;

·         Métodos;

·         Uma classe aninhada dentro de outra classe.

 

Porém a marcação não poderá ser utilizada nos seguintes casos:

·         Classes;

·         Interfaces;

·         Classes internas locais de métodos;

·         Métodos de classes internas;

·         Variáveis de instância;

·         Variáveis locais.

Variáveis e Métodos Estáticos: O modificador static é usado para criar variáveis e métodos que irão existir independentemente de quaisquer instâncias criadas para a classe. Em outras palavras, os membros static existem antes mesmo de você criar uma nova instância de uma classe, e haverá apenas uma cópia do membro static, independentemente do número de instâncias dessa classe.

Membro estático: bloco de inicialização e método main()

Um bloco de inicialização estático é executado quando a classe é carregada pela JVM (Java Virtual Machine) e serve para inicializar alguma informação necessária antes mesmo de se ter acesso a uma instância da classe.

O método main() tem uma diferença para outros métodos estáticos, ele é por padrão o método que diz ao Java que essa é a classe principal do projeto. Assim, o JRE saberá qual método será responsável pela inicialização da aplicação. Em uma aplicação Java SE, precisamos de pelo menos um método main() para executá-la, já em uma aplicação Java EE isto não é necessário.

A diferença entre um método estático e um bloco estático é bem visível. O método estático possui nome e um tipo de retorno e pode ainda possuir uma lista de argumentos, enquanto o bloco estático não possui nada disto. Além disso, um método ou variável do tipo estático pode possuir os modificadores de acesso do tipo private, protected, public ou default.

Na execução do código da Listagem 1, será impressa na tela a frase que está dentro do bloco estático. Veja que em nenhum momento esse bloco foi chamado dentro do método main(). Ele simplesmente é executado na

...