A Evolução da Linguagem Java

Tamanho: px
Começar a partir da página:

Download "A Evolução da Linguagem Java"

Transcrição

1 a r t i g o A Evolução da Linguagem Java Veja as mudanças da linguagem para o Java 7 e quais são as possíveis novidades para o futuro Roberto Perillo é bacharel em Ciência da Computação e está atualmente concluindo o curso de especialização em Engenharia de Software do ITA. Trabalha com Java há quase 5 anos, possui as certificações SCJP, SCWCD e SCJD, e participa ativamente dos fóruns do JavaRanch. Já trabalhou com JEE em grandes empresas, como Avaya e IBM, nesta última foi co-fundador do time de inovação de ibm.com GWPS Brasil. Eduardo Guerra é pesquisador em desenvolvimento de frameworks, participando de projetos opensource como SwingBean, Esfinge Framework, ClassMock e JColtrane. Atualmente está cursando doutorado no ITA, onde também já concluiu graduação em Engenharia da Computação e mestrado. Possui as certificações SCJA, SCJP, SCWCD, SCBCD (1.3 e 5.0), SCJWSD, SCMAD e SCEA e experiência como arquiteto de software nas plataformas Java SE, Java EE e Java ME. Atua também como professor na graduação do ITA e nos cursos de pós-graduação ITA/Stefanini. A linguagem Java é hoje uma das mais utilizadas em todo mundo. Em 2006, as estatísticas do Sourceforge apontavam que ela havia ultrapassado a linguagem C++ em número de projetos. Segundo o site TIOBE Software, que divulga um índice mensal a respeito da popularidade de linguagens de programação, em julho de 2009, Java é a linguagem mais popular entre os desenvolvedores. Esse índice se baseia no número de profissionais qualificados, cursos e serviços oferecidos no mercado, e também nas procuras realizadas em sites, como Google, MSN, Yahoo!, Wikipedia e YouTube. Analisando o histórico da linguagem neste índice, disponível desde 2001, ela se posicionou sempre entre a primeira e a segunda posição. Imagine agora como deve ser difícil realizar alterações em uma linguagem como Java. Cada mudança poderá afetar e ter um grande impacto sobre um número imenso de projetos e desenvolvedores em todo mundo, e por isso mesmo cada uma deve ser realizada com cuidado. Por exemplo, no Java 5, em que funcionalidades de linguagem foram acrescentadas, diversos programas não compilaram na nova versão devido a adição da palavra reservada enum, que muitas vezes era utilizada em identificadores, como para nomes de variáveis. Neste artigo, é apresentada com exclusividade uma entrevista realizada com Alex Buckley, o atual responsável na Sun pela linguagem Java e pela arquitetura da máquina virtual. Nesta entrevista, ele passa um pouco de sua enorme experiência na evolução da linguagem e dá algumas dicas a respeito do que podemos esperar de novidade no futuro da linguagem e da plataforma. O artigo também irá explorar mais a fundo as funcionalidades de linguagem previstas para entrarem no Java 7 e faz algumas previsões a respeito do que se pode esperar para outras futuras versões. 36

2 Entrevista com Alex Buckley Todos os anos, vários eventos sobre programação orientada a objetos são realizados ao redor do mundo, onde são apresentados diversos trabalhos focados ou baseados na linguagem Java. Particularmente, no meio científico, os que mais se destacam são o ECOOP (European Conference on Object Oriented Programming) que ocorre na Europa e o OOPSLA (International Conference on Object-Oriented Programming, Systems, Languages, and Applications) que acontece nos Estados Unidos. No OOPSLA do ano passado, mais especificamente no dia 22 de outubro, a revista Mundoj teve oportunidade de realizar uma entrevista exclusiva com Alexander Buckley, que é o atual responsável pelas especificações da linguagem Java e pela arquitetura da JVM. Nesta conversa, foi possível obter várias informações interessantes, como fatos ocorridos há mais de 10 anos que fazem parte da história da linguagem e indícios do que ainda está para entrar nela. Foi possível também ter noção do quão difícil é evoluir uma linguagem quando ela já está sendo amplamente utilizada na indústria. Por favor, descreva sua posição e suas responsabilidades na Sun Microsystems, Inc. Meu nome é Alex Buckley e sou o teologista computacional da linguagem Java e da máquina virtual Java (JVM). Dia a dia, isto significa que sou responsável pela especificação da linguagem Java e pela especificação da JVM. Estas definem, de uma forma independente de implementação, o significado da linguagem Java e da JVM. Eu não me preocupo com o comportamento do javac, ou qualquer das bibliotecas de classes, por exemplo. Eu só me preocupo com a definição da linguagem Java em si, o que ela faz e por que ela o faz de tal forma; e o mesmo para a máquina virtual. Obviamente, existem grandes sobreposições entre o design da linguagem e a máquina virtual, então manter as duas especificações sincronizadas tem sido historicamente grande parte do trabalho. Com mais linguagens começando a serem executadas na JVM, as especificações podem começar a ir em diferentes direções. Que tipo de coisas você busca em conferências acadêmicas como o ECOOP (European Conference on Object-Oriented Programming) e o OOPSLA (International Conference on Object- Oriented Programming, Systems, Languages, and Applications)? Nos dias de hoje, a orientação a objetos tem um papel muito importante na indústria. Outros paradigmas de programação, como a programação funcional ou lógica, têm seus seguidores, porém a orientação a objetos é o paradigma predominante. Congressos como o ECOOP e o OOPSLA apresentam muitos trabalhos baseados em linguagens predominantes na indústria, como Java ou C#. O que eu procuro nestes congressos são artigos que descrevam o núcleo de uma característica de linguagem. Não é um problema se esta característica não se pareça com Java, ou se é expressa em uma linguagem de brincadeira, ou até mesmo se é expressa formalmente em uma linguagem matemática. Eu não preciso saber que esta é uma extensão Java e a ideia na linguagem seria de tal forma, porque na prática, como as características são em linguagens reais é um tópico muito complicado. Por exemplo, você não pode inventar suas próprias palavras-chave porque isto quebraria código antigo. Eu procuro em artigos publicados no ECOOP e no OOPSLA pelo núcleo de uma ideia que possa ser adicionada à linguagem, então como elas são expressas não é um problema. Que tipos de características são interessantes? Bem, eu diria características de linguagem que suportam melhor modularidade de programas, assim como características de linguagem que suportam melhor análise de programas. Muitas pessoas não sabem, ou até saibam, mas não percebam o quão profundo isto é. A linguagem Java é quase única pelo fato de que a especificação da linguagem Java requer um compilador para executar alguns tipos de análise de programa. Na análise de alcance, não se pode ter declarações que nunca serão executadas. Na análise de declaração, deve-se sempre atribuir valores a variáveis finais e locais antes de usá-las. Isto na verdade é mandatório na especificação da linguagem Java. Se houver uma análise de programa útil que nós acharmos que vá beneficiar todos os desenvolvedores Java, há uma grande possibilidade de colocá-la nos padrões. Há muitas boas ideias sendo apresentadas nestes congressos. Quanto tempo leva para uma boa ideia ir do meio acadêmico para a indústria? Um enorme exemplo de uma característica proposta no meio acadêmico que foi adicionada à linguagem é, claro, generics. Assim que o Java foi lançado, o meio acadêmico ficou muito animado. Philip Wadler e Martin Odersky começaram a pensar como deveriam ser os tipos genéricos em Java. Como deveria ser a implementação? Teríamos que mudar só a linguagem ou a JVM também? Isto foi no final de 1996, quase tão logo o Java foi lançado. 37

3 Os generics foram algo em que o meu antecessor se envolveu muito. Isto foi na JSR 14, em Martin Odersky reescreveu o compilador Java, que se chamava GJ na época, para suportar generics, e aquela implementação dele se tornou o javac. Então o javac 1.3 era o compilador do Martin. Claro, os generics foram novamente estendidos para suportar os wildcards, e isto foi novamente o resultado de um trabalho acadêmico, de Mirko Viroli e Atsushi Igarashi, sobre variâncias, que são representadas na linguagem Java como?,? extends e? super. Este é um caso interessante no qual a pesquisa havia começado há anos, e assim que começamos a tentar aplicar o conceito a programas reais e a bibliotecas Java, descobrimos que o trabalho acadêmico não havia ido tão longe e precisa de mais desenvolvimento. Assim surgiram os wildcards. O oposto também acontece? Por exemplo, a indústria começa a usar algo e o meio acadêmico percebe que precisa pesquisar o assunto? Esta é uma pergunta interessante! No mundo do Java, muita inovação vem da implementação dos padrões ao invés dos próprios padrões. O grande objetivo do Java SE, Java ME e do Java EE é que existam padrões, e se você escreve seu código de acordo com estes padrões, você pode usar as bibliotecas e APIs destes padrões. O código vai funcionar com qualquer implementação, então muita inovação está em fazer implementações realmente eficientes ou fazê-las rodar em várias plataformas ou dispositivos bem pequenos. Os padrões evoluem, por natureza, de forma mais lenta do que a implementação, que pode usar vários truques. Isso aconteceu com anotações, talvez? Anotações na prática são populares e certamente habilitam muitos trabalhos acadêmicos, porque esses trabalhos precisam de metadados. Metadado não é um conceito muito complexo, e as anotações da linguagem Java são bem simples. O que os acadêmicos fazem com as anotações e o que é representado com as anotações é muito interessante. Eu diria que há funcionalidades na linguagem que suportam mais pesquisas acadêmicas, como o uso acadêmico das anotações. E a plataforma em si, tornando-se open-source com o JDK aberto, permite que as pessoas peguem o compilador Java, a JVM, o compilador Just-in- Time e façam experimentos neles. O quão difícil é evoluir uma linguagem? Podemos comparar esta evolução com a evolução de uma API, por exemplo? Existem alguns aspectos da linguagem que podem ser evoluídos. Existe a sintaxe da linguagem, o sistema de tipos da linguagem e o comportamento das instruções da linguagem. Muitas pessoas perguntam: É possível adicionar uma palavra-chave para fazer isso ou aquilo?, mas é bastante complicado mudar a sintaxe ou a gramática da linguagem Java. Não é possível simplesmente adicionar novas palavras-chave, pois qualquer palavrachave que você possa imaginar, alguém em algum lugar a estará usando como nome de variável. No passado, pudemos verificar que no momento em que uma nova palavra-chave é adicionada, alguns programas são quebrados, e não compilarão na última versão da linguagem Java. É muito mais difícil evoluir a sintaxe da linguagem do que as pessoas imaginam. É como evoluir a sintaxe da linguagem se você adiciona palavras-chave que só agem como palavras-chave quando for preciso, e em todos os outros lugares do programa, elas agem como identificadores. Então, se elas agem como nome de variável, ou nome de classe, ou nome de método hoje, elas continuarão agindo amanhã. Estas palavras-chave agem como palavras-chave somente em locais bem específicos, talvez no topo do arquivo-fonte, em que precisa ser uma palavra-chave. Realmente, é possível evoluir a sintaxe da linguagem, e aprendemos uma lição ao adicionar enum do Java 1.4 para o Java 1.5, que causou verdadeiras dores de cabeça a muitas pessoas. Aprendemos uma lição e não cometeremos este erro novamente. Não vamos, no futuro, adicionar palavras-chave que quebram o código-fonte. Evoluir a sintaxe é complicado e aprendemos como fazê-lo melhor. Evoluir o sistema de tipos da linguagem, e muitas propostas acadêmicas estão nesta área, é a coisa mais complicada. É muito difícil mudar o sistema de tipos Java, porque o sistema de tipos da linguagem Java (a) é refletido no sistema de tipos da JVM; (b) é embutido nas bibliotecas de reflexão, então seria necessário mudá-las também; e (c) novamente, sempre tem implicações em programas existentes, e a Sun não quer quebrar o código das pessoas só porque há algum novo tipo de sistemas mais elaborado. Mas é possível adicionar um novo tipo. O debate sobre closures foi efetivamente sobre se devemos adicionar funções à linguagem Java. A questão é se estaríamos adicionando algo tecnicamente seguro. Os generics sem os wildcards são seguros, mas muito restritos. Por isso, os wildcards foram adicionados, e há restrições nos wildcards que confundem as pessoas, mas que precisam existir, caso contrário você pode escrever um programa que compile, mas que trave em tempo de execução. Há algumas propostas que são aparentemente fáceis, mas que têm comportamentos complicados em tempo de execução. As pessoas dizem tudo bem, não tem problema, mas qualquer expert em sistemas de tipos irá lhe dizer que se você adiciona tipos estáticos, então o comportamento em tempo de execução deve ser previsível. É uma área muito complicada que tem um impacto enorme na plataforma e em programas. Assim, somos muito cautelosos ao fazer mudanças nessa área. Em relação a aspectos, quando iremos vê-los nativamente na linguagem Java? Estamos perto ou longe disso? Todos têm suas ferramentas, frameworks ou funcionalidades favoritas, que gostariam que fossem tiradas de uma API e fossem embutidas na linguagem Java. A dificuldade é que isto tornaria a linguagem Java mais difícil para todos aprenderem. Alguns gostariam de ver um framework orientado a aspectos adicionado à linguagem Java, outros gostariam de ver um framework orientado a recursos adicionado à linguagem Java. Uma linguagem não é nem uma aplicação nem uma API. Uma linguagem é melhor quando é menor e aplicações e APIs são melhores quando são maiores, pois assim podem ter mais poder e consequentemente terão mais usuários. Você só precisa se preocupar com as partes da API que você usa. Por outro lado, uma linguagem é melhor quando é menor, pois todo programador Java no mundo precisa entender efetivamente o significado de cada funcionalidade. 38

4 Então, se você faz dos joint points ou point cuts ou advices elementos de primeira classe na linguagem Java, você irá fazer duas coisas: primeiro, irá forçar todos os desenvolvedores Java a aprender aspectos. E mais, irá forçá-los a aprender aspectos como eles eram no dia em que você os embutiu na linguagem Java. Isto efetivamente pára novas pesquisas úteis sobre aspectos. Claro, existirão novos artigos sobre aspectos no futuro, mas uma vez que eles foram embutidos na linguagem, é a sua única chance de fazê-lo. Não dá para voltar e mudar depois disso. tiplas implementações, não somente um interpretador C nativo, mas também rodando na JVM, pois a JVM está em todos os lugares; em telefones celulares, em grandes servidores de aplicação. Então, todos ganham! O que mais pode ser adicionado ao que você disse no começo, sobre a JVM e a linguagem Java indo em direções diferentes? É uma estratégia ter a JVM suportando outras linguagens, com outras funcionalidades, para que o Java não precise mudar tanto? A JVM sempre foi capaz de executar outras linguagens-fonte, contanto que exista um compilador para elas. Não há nada na JVM que funcione somente para a linguagem Java. Podemos dizer que existem aproximadamente 100 linguagens-fonte que compilam para a JVM. Outra coisa a dizer é que muitas destas linguagens dinâmicas são mais velhas que o Java em si, como o Ruby, por exemplo. Então, não é surpresa que muitas linguagens além do Java têm sido executadas na JVM há muitos anos. Linguagens como Scala, que ainda estão em desenvolvimento, podem compilar para a JVM, então é possível comunicar-se com elas através de código Java, o que é muito interessante. É ótimo quando as pessoas olham para essas linguagens e expandem suas mentes, vendo novas formas de programar. Porém lembre-se de que estas linguagens estão livres para que seus designers removam funcionalidades a qualquer momento, ou redefinam funcionalidades. A Sun fica satisfeita quando pessoas escrevem outra linguagem que compila para a JVM e que tem o mesmo desempenho que código Java. A JVM é uma plataforma facilmente gerenciável, com muitas APIs. Tem uma ótima tradição quanto à segurança, e suas implementações atualmente têm ótimos compiladores Just-in-Time. Frequentemente, um compilador Just-in-Time na JVM consegue produzir código de máquina mais eficiente que um compilador C. E é interessante quando os criadores de outras linguagens também dizem que estão animados por verem suas linguagens tendo múl- Posso dizer que o que está acontecendo na JVM para suportar linguagens dinâmicas é muito interessante. Acontece que, hoje em dia, é possível rodar JRuby, Jython e outras linguagens dinâmicas na JVM. Elas eram bem lentas, e hoje têm um bom desempenho. Agora a pergunta é se podemos fazê-las rodar tão rápido quanto se fossem código Java. E o que estamos fazendo é colocar ganchos na JVM, para que alguém, como o implementador JRuby ou Jython, possa instruir a JVM sobre como otimizar código compilado do JRuby ou do Jython. O código compilado Java não precisa usar estes ganchos, já que o compilador Java frequentemente efetua otimizações entre o código-fonte Java e os bytecodes Java. Os bytecodes Java, sua forma, seu tamanho, é de certa forma entendido nativamente por compiladores Just-in-Time. Mas ao rodar classes compiladas do JRuby ou Jython, o compilador Just-in-Time precisa de uma pequena ajuda para otimizar estes bytecodes. Está é a proposta da JSR 292. Dá até para imaginar o compilador Java também usando este mecanismo, sem mudanças na linguagem Java, somente como uma técnica de otimização. Também surge a ideia de que a linguagem Java em si poderia ser mais dinâmica. O que isto significa? Significa, por exemplo, que código Java poderia chamar métodos em código Ruby ou Python, compilados pelo JRuby ou Jython. Métodos Ruby e Python não possuem tipos em seus códigos-fonte. Atualmente, tudo no Java assume que o que está sendo chamado possui tipos. Achamos que provavelmente vai ser muito útil poder efetuar chamadas entre linguagens, principalmente quando estas outras linguagens estiverem rodando bem rápido na JVM e quando houver mais códigos escritos nestas linguagens rodando na JVM. Após a adição de novas funcionalidades de linguagem no Java 5, houve uma grande discussão a respeito do que poderia aparecer nas novas versões. Apesar de algumas das funcionalidades nas seções seguintes estarem praticamente confirmadas no Java 7, a verdade é que nada é certo ainda. As funcionalidades que serão apresentadas dão uma noção de como será a cara da linguagem na sua próxima versão. Este artigo se limita a abordar as funcionalidades relacionadas com mudanças na linguagem, porém diversas outras mudanças, como, por exemplo, em APIs e na máquina virtual, também estão previstas. Uma que vale a pena ser comentada é o Projeto Jigsaw (que em português seria algo como serra tico-tico), que visa a modularização da JDK 7. Este trabalho permitirá, por exemplo, que uma aplicação seja implantada apenas com os componentes da JDK que ela realmente precisar, o que poderá escalar a JDK para dispositivos menores e mais simples. Uma novidade interessante para os fãs das linguagens dinâmicas que também está prevista para a JDK 7 é um melhor suporte da máquina virtual para outras linguagens (ver última pergunta da entrevista com Alex Buckley). O objetivo é a criação de extensões para a máquina virtual que suportem a implementação de linguagens não-java em um nível de desempenho próximo da própria linguagem Java. As próximas subseções abordam as funcionalidades da linguagem que provavelmente irão "dar as caras" no Java 7. Serão abordadas as anota- 39

5 ções de tipo e outras possíveis mudanças em anotações, o novo suporte a programação modular e outras pequenas melhorias de linguagens agrupadas no chamado Project Coin. Anotações em Tipos A JSR 308, intitulada de Type Annotations, tem como objetivo estender o sistema de anotações existentes para que elas possam aparecer em qualquer local onde possa ser utilizado um tipo. No Java SE 6, é possível anotar declarações de classes, métodos, atributos e variáveis, e com essa adição, será possível no Java SE 7 que as anotações possam ser utilizadas para outros fins. A aplicação mais imediata desse novo mecanismo seria para o uso na JSR 305 Annotations for Software Defect Detection, que possui como objetivo a definição de anotações para verificações estáticas em tempo de compilação, visando a detecção de problemas que hoje acabam sendo detectados apenas em tempo de execução. Um exemplo seria a na declaração de variáveis, para as quais uma ferramenta faria uma verificação em tempo de compilação e acusaria um erro se existe a possibilidade da mesma assumir o valor nulo. Segundo o próprio documento que propõe a adição, o uso desse mecanismo de detecção de defeitos seria limitado sem as anotações de tipo, pois se perderia facilmente o rastro das variáveis anotadas quando fosse feito o uso de tipos genéricos, quando fosse feita a invocação de um método em um objeto, quando fosse efetuado um cast, quando uma classe fosse estendida etc. Para se ter uma ideia de como seria a sintaxe desse novo tipo de anotação, abaixo segue uma lista com alguns exemplos: String> list; construtores String>metodo( string ); class BeanPresenter<E Bean> { Collection <? Bean> col; interface E> { class UnmodifiafleList<T> T> { void createconnection() IOException { Na verdade, todo método de instância recebe um parâmetro implícito 'this'. Esta anotação é no tipo de 'this' e é colocada entre a lista de parâmetros e a cláusula 'throws'. public String { // array de arrays de documentos somente Document [][] docs1; // array somente leitura de arrays de documentos [][] docs2; // array de arrays somente leitura de documentos Document [] docs3; mystr = String) obj; Person p = Person(); if(str String){ String> c Type.field A primeira impressão que se tem quando do primeiro contato com a sintaxe desse novo tipo de anotações é que o código ficará extremamente confuso com a adição dessas novas informações. Imagine, por exemplo, a definição da variável Document>> files; Por esse motivo, é possível encontrar diversas opiniões em blogs na internet criticando essa nova feature da linguagem como os posts When You Should Jump? JRS 308. That's When. e What Hath Java Wrought que argumentam que o código pode ficar extremamente confuso e verboso com o uso desse novo tipo de anotação. Com a discussão iniciada, outros se posicionam a favor, como o post JSR 308 Animosity, que critica essa animosidade gerada a essa nova funcionalidade da linguagem. Na verdade, essa nova funcionalidade é de uso opcional da mesma forma que o Generics, o que significa que ninguém será obrigado a utilizar essas anotações se não quiser. Ela permite apenas que novas metainformações possam ser adicionadas aos tipos, porém essa JSR não trata do significado ou semântica dessas anotações (o que fica, por exemplo, a cargo da JSR 305). Assim também como com a utilização de Generics, com o uso dessa funcionalidade pode-se fazer coisas muito interessantes, porém a codificação se torna mais difícil e o código mais poluído. Apesar de podermos pensar que String é um tipo que não pode receber atribuições de uma outra variável do tipo String (sem anotações) String, a ideia é que essa verificação seja feita por plugins que irão atuar em tempo de compilação. Na arquitetura da máquina virtual, nada seria alterado no sistema de tipos da linguagem. class Statue Statue() { Apesar da primeira aplicação pensada para essas anotações ser seu consumo estático em tempo de compilação, elas também poderão ser acessadas em tempo de execução. Como a API Reflection não dá acesso ao corpo dos métodos, em alguns tipos de uso essas anotações 40

6 não poderão ser recuperadas em tempo de execução, como seu uso em variáveis locais, com o operador instanceof, em casts de tipos etc. Porém, em outros casos, como seu uso em geral na assinatura de métodos e na declaração de tipos e variáveis de classe, será possível a recuperação. A modificação que será realizada na API Reflection é bem pequena: basicamente a classe Type passará a implementar a interface AnnotatedElemment, que possui métodos que permitem a recuperação de anotações. O quadro Utilizando Type Annotations para Problemas Reais irá apresentar exemplos de aplicação desse tipo de anotação, para que os leitores possam avaliar os ganhos que se pode ter com essa adição em relação à complexidade que é adicionada na sintaxe da linguagem. Utilizando Type Annotations para problemas reais Para quem quiser experimentar as Type Annotations, existe uma ferramenta preliminar que permite o uso desse tipo de anotação. O Checker Framework (ver referências) é uma ferramenta que provê plug-ins para o javac, que verificam e previnem erros em tempo de compilação. Um desenvolvedor pode utilizar esse plug-in sem que seus companheiros de trabalho precisem utilizá-lo, bastando que eles não acionem os plug-ins no momento de executar o javac. O Checker Framework vem com tudo que você precisa, incluindo ferramentas que facilitam a criação de novos verificadores. As anotações que já são suportadas pelo Checker Framework podem ser consideradas como uma prévia das que virão na JSR 305 Annotations for Software Defect Detection. Esse tipo de verificação é uma ferramenta muito valiosa para arquitetos que desejam assegurar que determinadas propriedades no código sejam seguidas por todos os desenvolvedores em um projeto maior. Esse framework possui os seguintes tipos de verificação: este verificador através de anotações checa se em algum ponto do código existe a possibilidade de se invocar um método em uma referência nula. Esse tipo de prática evita que em tempo de execução seja lançada a indesejável e famosa NullPointerException. Existem anotações para opções mais avançadas, que permite que uma instância seja nula, porém não depois que ela for inicializada. esse verificador irá procurar por usos incorretos do operador == e do método equals() para realizar a comparação de igualdade entre objetos. Interning, também conhecido como canonicalização, é um padrão de projeto no qual sempre que duas referências podem ser consideradas iguais, elas estarão apontando para a mesma instância. A marca esse tipo de referência e evita que erros como o representado abaixo aconteça: Integer x = new Integer(23); Integer y = new Integer(23); System.out.println(x == y); // imprime false! este verificador, através de procura erros que apontam locais que modificam indevidamente propriedades de objetos. O uso desse verificador evitaria, por exemplo, que uma lista ou seus objetos recuperados de um cache, fossem modificados externamente a ele de forma indevida, causando efeitos colaterais indesejados a outros clientes desse cache. o objetivo desse verificador é prevenir alguns erros de concorrência. A deve ser utilizada em tipos de variáveis que só devem ser acessadas quando um determinado lock é obtido. A já anota métodos que só devem ser chamados se um determinado lock foi obtido por quem o está chamando. O objetivo desse pequeno resumo não foi ensinar com detalhes como utilizar cada uma das anotações dos verificadores, mas fornecer uma visão geral do tipo de coisa que poderá ser implementada como esse novo recurso. O link para o manual do Checker Framework pode ser encontrado nas referências deste artigo. No material pesquisado, não foi encontrado nenhum exemplo referente à utilização das anotações de tipo em tempo de execução, porém analisando a API do EJB 3, por exemplo, é possível identificar alguns possíveis usos. A deve ser utilizada em classes de exceções, de runtime ou não, que devem ser encaradas como erros de negócio. Quando uma exceção desse tipo é lançada, só é dado o rollback da transação quando a anotação possui o atributo 'rollback = true'. Com esse tipo de abordagem, uma mesma classe de exceção não pode ser utilizada em situações em que o comportamento em relação ao rollback ou não das exceções seja diferente. Com o uso de anotações em tipos, um método que lança exceções poderia ter em sua própria assinatura, na declaração das exceções, a definição de quais delas devem fazer com que o container faça ou não o rollback da transação corrente. Obviamente, essa funcionalidade é apenas uma previsão, mas ilustra como uma nova gama de opções e possibilidades pode ser aberta com essa adição à linguagem. Apesar da JSR 308 se chamar Type Annotations, ela também abrange em seu escopo outras possíveis modificações no sistema de anotações da linguagem Java. Na verdade, esse nome foi adotado para evitar um nome vago como Extensions to Java s Annotation System e pelo fato da principal mudança ser a inclusão das anotações de tipo. A JSR 308 não possui a intenção de ser a última JSR sobre a definição de anotações na linguagem Java e é aceitável que sejam deixadas questões pendentes para serem consideradas em novas JSRs, que serão incorporadas em versões futuras da linguagem. Abaixo seguem algumas possíveis modificações no sistema de anotações da linguagem. Algumas são bem suaves e contêm pequenas modificações que visam simplesmente simplificar a sintaxe, enquanto outras são modificações mais profundas e exigem que internamente grandes modificações sejam feitas. na linguagem Java, não é permitido que uma mesma anotação seja utilizada duas vezes. Esse tipo de restrição faz com que seja necessária a criação de uma anotação com uma lista da anotação que se deseja repetir. Isso pode ser visto, por exemplo, na da API JPA que precisa ser encapsulada pela conforme o exemplo abaixo: 41

7 = "todaspessoas", query = "SELECT p FROM Pessoa = "pessoanome", query = "SELECT p FROM Pessoa p WHERE p.nome = :nome") ) public class Pessoa { Com a implementação dessa modificação, será possível eliminar a e colocar várias diretamente na classe, conforme o código a = "todaspessoas", query = "SELECT p FROM Pessoa = "pessoanome", query = "SELECT p FROM Pessoa p WHERE p.nome = :nome") public class Pessoa { também estão sendo estudados outros locais, além dos apresentados nas anotações de tipo, para a adição de anotações. Dentre eles estão anotações em comandos ou em um grupo de comandos, como loops e blocos. Os defensores dessa proposta argumentam que esse tipo de anotação traria benefícios para verificações de atomicidade e concorrência. Dentre as alterações necessárias estariam a definição da sintaxe e do formato do arquivo.class para armazenar essa informação. Dentre outras possibilidades também analisadas estão as anotações para expressões, para as quais ainda não se tem uma aplicação comprovada que justifique sua adição, e anotações para apenas certos tipos de comandos, que não apresenta muitos benefícios em relação à proposta mais geral. atualmente, uma anotação não pode herdar características de outras, o que dificulta a extensão de processadores de anotações, que devem atuar em um conjunto fixo de anotações. O recurso utilizado para contornar esse problema é meta-anotar uma anotação, para que o interpretador possa ler essa meta-anotação, como utilizado em frameworks como o Hibernate Validator e o JColtrane. A ausência de herança também limita bastante a expressividade das anotações. Considere uma que recebe uma com uma expressão a ser verificada: a == b )) public void method() { Sem herança, é impossível definir outra anotação que possa ser colocada no lugar como uma anotação que faz uma negação ou uma anotação que junta duas expressões como no exemplo abaixo: a < b ), exp2 < c)) public void method() { Existem duas soluções descritas na definição da JSR que estão sendo consideradas para a herança: a possibilidade de uma anotação estender outras anotações e a possibilidade de uma anotação estender e implementar interfaces. existem algumas limitações na expressividade das anotações, sendo exemplos o fato de uma anotação não poder receber uma anotação arbitrária como argumento e o fato de uma anotação não poder possuir uma definição recursiva. Esses tipos de estrutura já se provaram eficientes em outras tecnologias, como, por exemplo, XML e YAML. Para que isso seja possível, seria necessário para finalizar uma recursão outras adições, como a possibilidade de possuir argumentos nulos na anotação (que hoje também não é possível, somente valores default). a sintaxe das anotações quando elas recebem um argumento pode ser simplificada quando a mesma possui a propriedade value, o qual pode ser omitido. Exemplificando, no lugar de = 13), é possível colocar Infelizmente, quando é necessário definir mais de um argumento, essa simplificação não é possível e a sintaxe fica mais verbosa. Está sendo estudada uma forma de definir uma posição para os argumentos de forma que os nomes possam ser omitidos. Outra questão sendo abordada nesse tópico é a obrigatoriedade do nome value para a propriedade default, cujo nome pode ser omitido. Muitas vezes, esse nome não é significativo em relação ao domínio. A ideia é permitir que na definição da anotação seja definido, possivelmente através de uma anotação qual é o campo que será considerado caso o nome do argumento não seja definido explicitamente. atualmente, é possível definir uma anotação que será herdada pelas subclasses de uma classe anotada através do uso da Porém, essa herança é somente das anotações da superclasse e anotações definidas nas interfaces, por exemplo, não são herdadas. Poderia também ser interessante que anotações pudessem ser herdadas nos membros da classe, como em métodos sobrepostos e construtores. diversas APIs possuem anotações de métodos que, ao serem definidas na classe, servem como uma definição default para os métodos da classe. Um exemplo seria a da especificação EJB 3. Porém, esse tipo de comportamento é implementado pelo componente que processa as anotações e não existe um mecanismo padrão para esse tipo de definição, que pode diminuir e simplificar o código. Uma possível mudança seria a definição de uma anotação para possibilitar esse tipo de definição, conforme o exemplo abaixo: a )) class Exemplo { Para que esse tipo de definição seja possível, também seria preciso que a funcionalidade que permite anotações possa possuir como argumentos anotações de tipos arbitrários. Como foi dito por Alex Buckley em sua entrevista, a introdução de anotações na linguagem Java permitiu o desenvolvimento de diversos trabalhos interessantes que utilizavam esse mecanismo para incorporar novas informações nas classes, permitindo o desenvolvimento de novas funcionalidades. Essas adições nas anotações visam uma maior expressividade das informações e simplificação na sintaxe, além de introduzi-las em novos locais abrindo uma nova gama de possibilidades para sua utilização. 42

8 Suporte de linguagem à modularização As JSRs 277 (focando em deployment e empacotamento) e 294 (focando em modularidade de APIs em tempo de desenvolvimento) introduzem o conceito de superpackages. O problema que este conceito procura solucionar diz respeito a relações hierárquicas entre pacotes. Por exemplo, ao tornar uma classe pública, ela passa a fazer parte de uma determinada API. Atualmente, não existe uma forma nativa de dizer que uma classe, mesmo pública, é pública somente para alguns pacotes e não acessível (algo como o modificador de acesso default) para outros pacotes. Existem ferramentas, como JDepend, por exemplo, que podem prover esse tipo de verificação antes ou depois da compilação, mostrando que existe no mercado essa necessidade. Os superpackages fornecem uma forma de expressar essa relação hierárquica entre pacotes, que podem ter membros públicos para a implementação de determinados pacotes, porém que não devem ser visíveis para outros pacotes. Assim, pacotes que estão organizados dentro de um superpackage podem acessar classes públicas entre si, mas ao mesmo tempo, pacotes que estão fora deste superpackage não podem acessar essas classes, a menos que estas sejam exportadas. O exemplo da listagem 1 mostra como os superpackages devem aparecer na linguagem: Na verdade, um superpackage é uma unidade de compilação onde serão definidos os pacotes que terão acesso a classes públicas de outros pacotes e quais classes públicas poderão ser vistas de fora dessa unidade de compilação. Para se definir um superpackage, será preciso criar um arquivo super-package. java no local onde este será definido. Para o exemplo da Listagem 1, o caminho completo do arquivo é com/mundoj/java7/super-package.java. Nele, é definido que os pacotes com.mundoj.java7, com.mundoj.java7.interview e com.mundoj.java7.typeannotations farão parte deste superpackage, assim como os superpackages com.mundoj.java5 e com.mundoj.java6. A classe HelloWorld é exportada, o que significa que esta classe estará disponível fora deste superpackage. O pacote membro com.mundoj.java7.interview também é exportado, o que significa que seus membros públicos também poderão ser acessados de fora deste superpackage, ao contrário do pacote com.mundoj. java7.typeannotations, que não é exportado. Mesmo sendo uma característica nova na linguagem, não será obrigatória sua utilização, podendo assim ser ignorada. Isto é essencial para que haja compatibilidade com código já desenvolvido, o que é uma das principais preocupações ao se introduzir uma nova funcionalidade na linguagem. Essa é uma característica que possibilita a relação entre pacotes em nível de classe, mas ainda não existe nada que possa informar que um método deve ser público para determinados métodos e não acessível para outros métodos. Pequenas melhorias na linguagem Project Coin O objetivo do Project Coin é determinar o conjunto de pequenas alterações de linguagem que deve ser adicionado ao Java 7. A submissão de propostas foi até o dia 30 de março deste ano e os interessados deveriam preencher um formulário com diversos itens que descrevem a mudança desejada. Essa proposta deve descrever os seus benefícios e as desvantagens da proposta, além de apresentar alternativas existentes sem mudanças na linguagem. Também deveria ser mostrado um exemplo simples, com o objetivo de exemplificar rapidamente o uso da nova funcionalidade, e um exemplo avançado, que deve mostrar como seria o Listagem 1. Exemplo de superpackage. superpackage com.mundoj.java7 { // Pacotes membros member package com.mundoj.java7; member package com.mundoj.java7.interview; member package com.mundoj.java7.typeannotations; // Superpackages membros member superpackage com.mundoj.java5; member superpackage com.mundoj.java6; // Classe exportada (pode ser acessada de fora do superpackage) export com.mundoj.java7.helloworld; // Pacote exportado export package com.mundoj.java7.interview; funcionamento em casos mais complexos. Outra parte importante da proposta é a que analisa o impacto que elas teriam no que já existe hoje, como na gramática da linguagem e no formato das classes compiladas em bytecode. Também se deve levar em consideração como essa funcionalidade pode ser testada, se é necessário o suporte de bibliotecas e se são necessárias alterações na API de reflexão. Mudanças em outras ferramentas e partes da plataforma como serialização e o javadoc também devem ser consideradas. Na parte final da proposta, um quesito que é crítico na aceitação da mudança diz respeito à compatibilidade: essa mudança quebra algum código existente? Como programas feitos na versão anterior interagem com esta funcionalidade? As seções seguintes descrevem algumas das propostas do Project Coin mais comentadas e com mais probabilidade de serem incorporadas na linguagem Java. É importante ressaltar que essas ainda são propostas e que, ao serem consideradas dentro de uma JSR, podem sofrer modificações, serem deixadas para versões futuras ou mesmo serem definitivamente descartadas. Atualmente, estruturas switch do Java suportam somente os tipos primitivos byte, short, char, int, as classes wrapper (Character, Byte, Short, Integer) e constantes enum. Alguns desenvolvedores utilizam o hashcode (que na verdade é um inteiro) de variáveis String para sua utilização no case do switch, simulando de certa forma a utilização de Strings em estruturas switch. Um dos problemas dessa abordagem é que o código fica pouco legível. Muito possivelmente, a versão 7 da linguagem Java suportará também Strings em estruturas switch de forma nativa. Desta forma, será possível escrever o código apresentado na Listagem 2. A estrutura de controle switch não é uma das favoritas na comunidade de desenvolvimento, sendo que seu uso é classificado por alguns como uma má prática. O próprio livro de Martin Fowler sobre refatoração fala que em cada switch existe um "mal cheiro", para o qual vale a pena verificar se não deve ser utilizado polimorfismo. Dessa forma, pode-se questionar se realmente vale a pena investir nessa modificação, que talvez incentive ainda mais o uso dessa estrutura. 43

9 Listagem 2. String em uma estrutura switch. public void ouvirmusica(string nome) { switch (nome) { case Beto : { System.out.println( Vamos ouvir John Lennon ou Pink Floyd? ); break; case Guerra : { System.out.println( Vamos ouvir Jewel ou Alanis Morissette? ); break; default: { System.out.println( Vamos ouvir Led Zeppelin! ); Enums são ordenados por natureza. Atualmente, para se comparar constantes enum, utiliza-se comumente o método compareto(), que é disponível implicitamente a tipos enum. Embora funcione, é pouco intuitivo e pouco legível. Por exemplo, atualmente, podemos comparar constantes enum conforme apresentado na Listagem 3. Listagem 3. Comparação de constantes enum com o método compareto(). enum Tamanho {PEQUENO, MEDIO, GRANDE Tamanho meutamanho = Tamanho.GRANDE; Tamanho seutamanho = Tamanho.MEDIO; if (meutamanho.compareto(seutamanho) > 0) { System.out.println( Minha camisa vai ficar um pouco grande em voce! ); Na Listagem 3, o resultado do método compareto() é 1 porque a constante GRANDE aparece uma posição depois da constante MEDIO. Assim, se existisse outra constante chamada MUITO_GRANDE depois da constante GRANDE, e seu valor fosse atribuído à variável meutamanho, então o resultado da chamada do método compareto() seria 2. Além da forma apresentada na Listagem 3, os operadores de comparação == e!= também podem ser utilizados. A partir do Java 7, muito possivelmente, também poderão ser utilizados os outros operadores de comparação, como exemplificado na Listagem 4. Espera-se também que o desempenho dessa comparação seja melhorado com essa modificação. Listagem 4. Comparação de constantes enum no Java 7. enum Tamanho {PEQUENO, MEDIO, GRANDE Tamanho meutamanho = Tamanho.GRANDE; Tamanho seutamanho = Tamanho.MEDIO; if (meutamanho > seutamanho) { System.out.println( Minha camisa vai ficar um pouco grande em voce! ); Outra nova funcionalidade interessante que possivelmente aparecerá na próxima versão da linguagem são as chamadas encadeadas, em que métodos void implicitamente retornarão this (que se refere sempre ao objeto atual). Isto tornará a fluent interface mais fácil de ser utilizada. A Listagem 5 mostra um exemplo de chamadas encadeadas. Uma das críticas a essa funcionalidade é que ela irá alterar o uso de APIs Listagem 5. Chamadas encadeadas. public class Pessoa { private String nome; private int idade; // Métodos getter e setter omitidos public void cumprimentar() { System.out.println( Ola, meu nome eh + nome +! ); // Instanciando um objeto da classe Pessoa Pessoa pessoa = new Pessoa(); // Chamadas encadeadas pessoa.setnome( Beto ).setidade(26).cumprimentar(); já existentes, causando sintaxes e usos inesperados da mesma. Isso pode gerar uma fonte de novos bugs e até mesmo quebrar código já existente, o que é algo indesejado em qualquer nova funcionalidade da linguagem. Como essas funcionalidades ainda são apenas propostas, é preciso esperar para ver se ela será mesmo implementada ou se haverão mudanças na ideia original. Uma das ideias que poderão surgir como melhoria na linguagem é a inferência de tipos ao instanciar classes genéricas. Por exemplo, atualmente, para se instanciar um HashMap (que é uma classe genérica), é preciso declarar a variável com as mesmas informações do tipo. Um artifício comumente utilizado por desenvolvedores é a utilização de fábricas estáticas para que isso não seja preciso. A Listagem 6 ilustra as duas abordagens. Listagem 6. Instanciando classes genéricas. // Criando um HashMap a partir do Java 5 Map<Integer, String> mapa = new HashMap<Integer, String>(); // Criando um HashMap utilizando uma fábrica estática Map<Integer, String> outromapa = makehashmap(); // Fábrica estática de HashMap static <K, V> HashMap<K, V> makehashmap() { return new HashMap<K,V>(); A partir do Java 7, a classe genérica possivelmente poderá assumir automaticamente a mesma parametrização do tipo da variável. Assim, a expressão de criação de instâncias de classes genéricas será da forma mostrada na Listagem 7. Listagem 7. Instanciando classes genéricas a partir do Java 7. Map<Integer, String> mapa = new HashMap<>(); List<String> lista = new ArrayList<>(); Além disso, a partir do Java 7, as informações sobre os generics poderão estar disponíveis também em tempo de execução. Quando os generics foram introduzidos na linguagem, foi definido que suas informações estariam disponíveis somente em tempo de compilação, para que houvesse compatibilidade com códigos criados antes dos generics. Na próxima versão do Java, existe a possibilidade que essas informações sobre o tipo genérico de uma instância também possa ser acessada em tempo de execução através da API Reflection. 44

10 Possivelmente, a cláusula catch de tratamento de exceções terá duas mudanças significativas. A primeira delas é que será possível pegar mais de uma exceção por bloco e tratá-las igualmente. Muitas vezes, o tratamento que precisa ser dado a exceções em um bloco que pode lançar mais de um tipo de exceção é igual para todas. Isso é especialmente problemático quando essas exceções são de hierarquias distintas. Por exemplo, atualmente, é comum encontrarmos um código como o da Listagem 8. Listagem 8. Mesmo tratamento aplicado a mais de uma exceção. try { return klass.newinstance(); catch (InstantiationException exception) { throw new AssertionError(exception); catch (IllegalAccessException exception) { throw new AssertionError(exception); A partir do Java 7, deverá ser possível pegar várias exceções na mesma cláusula catch e tratá-las da mesma forma. A Listagem 9 mostra como isso poderá ser feito. Listagem 9. Tratamento de exceções no Java 7. try { return klass.newinstance(); catch (InstantiationException IllegalAccessException exception) { throw new AssertionError(exception); Além disso, a cláusula catch também deve sofrer outra alteração significativa. Em algumas situações, muitos desenvolvedores escolhem definir somente uma cláusula catch para tratar quaisquer exceções que possam ser lançadas a partir de um bloco try, e após tratá-las, relançam estas exceções. Para isso, basta definir uma única cláusula catch com um tipo mais amplo do que as exceções que podem ser lançadas no bloco try (como Throwable, por exemplo). O problema é que neste caso, o tipo da exceção pode se tornar mais amplo do que as exceções indicadas na assinatura do método, o que torna impossível relançar as exceções no momento do tratamento. Por exemplo, o código apresentado na Listagem 9 causará um erro de compilação. Listagem 9. Erro de compilação ao lançar uma exceção mais ampla do que as indicadas na assinatura do método. public void metodoarriscado() throws IOException, RemoteException { try { // Bloco try lançando vários tipos de exceções catch (Throwable exception) { // A exceção poderia ser tratada aqui throw exception; // Erro de compilação: Unhandled exception type Throwable O erro de compilação mostrado na Listagem 9 acontece porque o tipo Throwable é mais amplo do que IOException ou RemoteException, que são as exceções que o método pode lançar. A partir do Java 7, será possível aplicar o mesmo tratamento para quaisquer exceções e relançá-las, mesmo que o tipo indicado na cláusula catch seja mais amplo do que os indicados na assinatura do método. Por exemplo, o código da Listagem 10 mostra como esse tipo de comportamento será implementado no Java 7. Listagem 10. Código válido a partir do Java 7. public void metodoarriscado() throws IOException, RemoteException { try { // Bloco try lançando vários tipos de exceções catch (final Throwable exception) { // A exceção poderia ser tratada aqui throw exception; // Sem erro de compilação Ao adicionar a palavra-chave final à declaração da exceção na cláusula catch, o compilador entende que as únicas exceções verificadas que podem estar sendo tratadas são as lançadas pelo bloco try, e desde que essas exceções estejam declaradas na assinatura do método, é possível relançá-las, mesmo que o tipo indicado na cláusula catch seja mais amplo do que os indicados na assinatura do método. Uma vez que uma interface está definida, não é possível adicionar novos métodos sem quebrar as implementações existentes. Isso porque as classes que implementam a interface não possuem implementações dos novos métodos. Por exemplo, ao adicionar novos métodos à interface java.sql. ResultSet, todas as implementações atuais se tornariam inválidas. Como forma de contornar este problema, em algumas APIs existem métodos estáticos utilitários que criam novas funcionalidades, como exemplo, pode ser citada a classe Collections. Esses métodos são pouco convenientes de serem utilizados e dificultam a legibilidade do código. Uma proposta de funcionalidade feita por Neal Gafter, chamada de Extension Methods, seria a possibilidade de adicionar métodos estáticos a interfaces já existentes. A versão mais simples dessa proposta, exemplificada na Listagem 11, permite que métodos importados estaticamente possam ser utilizados como membros do seu primeiro argumento. Listagem 11. Exemplo de métodos de extensão. // Importação estática de métodos import static java.util.collections.sort;... List<String> list = new ArrayList<>(); // É como se o método sort() fizesse parte da interface List, mas na verdade // em tempo de compilação isso é convertido para a chamada sort(list) list.sort(); Essa proposta gerou discussões como possíveis conflitos de nome gerados por importações estáticas e a possibilidade de adicionar métodos em classes com o modificador 'final', o que poderia gerar uma nova fonte de bugs em aplicações. Como forma de contornar esses problemas, foi proposto que os métodos nos quais isso poderia ser utilizado deveriam ser marcados através de uma nova sintaxe ou através de uma anotação. Outra modificação na proposta original seria a dos métodos invocados dessa forma possuírem uma sintaxe diferenciada, como list.do.sort() ou list->sort(). Essas propostas entram em conflito com um dos objetivos de Neal Gafter quando fez a proposta, que era de simplificar esse tipo de chamada sem modificar a sintaxe da linguagem. Devido a essas questões, talvez essa funcionalidade acabe sendo deixada de fora, porém isso só o tempo irá dizer. 45

11 Apesar das mudanças do Java 7 parecerem significativas, ainda existem diversas propostas de mudanças que não entrarão nessa versão e que muitos apostam que no futuro podem ser incorporadas na linguagem. As duas subseções seguintes irão falar um pouco sobre duas funcionalidades sobre as quais existe bastante discussão de quando e como elas serão inseridas na linguagem. A primeira delas são as closures, cuja não-inclusão no Java 7 foi a grande decepção da comunidade. A segunda funcionalidade é a programação orientada a aspectos, que é um paradigma que vem ganhando cada vez mais adeptos. Closures Embora mencionado na entrevista, os closures muito provavelmente aparecerão na linguagem somente em alguma versão posterior ao Java 7. Esta funcionalidade (ou pelo menos algo parecido) já é suportada em várias linguagens atualmente, a maioria delas dinâmicas. Quase todas as linguagens que foram introduzidas há menos de dez anos suportam algo do tipo. Ainda não existe um consenso sobre como eles aparecerão na linguagem Java; atualmente existem várias propostas, sendo três delas principais. Existem várias definições para closure, sendo que a mais importante é função anônima. A teoria da Ciência da Computação chamaria isso de expressão lambda, e na verdade este conceito não é novo; datando de trabalhos teóricos da década de As implementações mais antigas e importantes foram nas linguagens Scheme e Smalltalk. Um fato curioso é que praticamente todas as linguagens que podem ser executadas na JVM, exceto a linguagem Java, possuem algo parecido com closures. Embora ainda não exista sequer uma JSR para os closures, é possível ter uma ideia de como essa funcionalidade poderia ser inserida na linguagem. A Listagem 12 dá o exemplo baseado em uma das propostas, de como os closures poderiam ser implementadas. Nesse exemplo, closure é definida como um tipo que recebe parâmetros e retorna um resultado. É como um trecho de código que pode ser passado como parâmetro e possui acesso a elementos locais relativos a onde a closure foi definida. Assim, closure é uma função anônima, que pode ou não definir parâmetros e até variáveis internas, e pode aparecer na forma de atribuição ou ser somente uma expressão de resultado. Este tipo de funcionalidade seria de grande utilidade, por exemplo, na API de concorrência. Uma Thread poderia ser criada a partir de uma closure com o código que ela deveria executar. O uso de closures tornaria o código menos verboso e mais simples de ser entendido. Não está no escopo deste artigo descrever com detalhes uma ou mais propostas de implementação de closures na linguagem Java (mesmo porque isso por si só já daria um grande artigo). Nosso objetivo é apresentar de uma forma breve o que são as closures e tentar especular um pouco a respeito de sua implementação nativa na linguagem. Houve uma grande decepção na comunidade a respeito das closures não terem sido incluídas dentre as funcionalidades do Java 7, pois foram feitos diversos protótipos e foi criada uma grande expectativa a respeito. Na conversa da equipe da revista com Alex, ele deu a entender que as closures muito provavelmente estarão no futuro da linguagem. Dentre os fatores que pesaram para deixá-las fora do Java 7 está a questão de que quando uma funcionalidade é adicionada na linguagem, não é mais possível adotar uma abordagem diferente e cria-se um compromisso de Listagem 12. Exemplos de Closures. // Um closure que soma dois números {int, int => int soma = {int x, int y => x + y; int total = soma.invoke(2, 2); // Um closure que não retorna valor; somente efetua uma operação {String => void cumprimentar = {String nome => System.out.println( Ola, + nome);; cumprimentar.invoke( Beto ); compatibilidade em todas as versões futuras. Com a diversidade das propostas, talvez tenha se percebido que se deve estudar mais a fundo qual seria a forma mais adequada de introdução de closures na linguagem. Aspectos nativos na Linguagem Java? A programação orientada a aspectos é um paradigma de programação (porém que alguns consideram apenas uma nova técnica de modularização) que tem como objetivo a separação dos interesses transversais em uma aplicação. Os interesses transversais caracterizam requisitos funcionais ou não-funcionais que normalmente estão espalhados pelo código, pois estão presentes em diversos pontos da aplicação. Exemplos comuns desse tipo de interesse são segurança, transacionalidade e logging, porém existem diversos exemplos de requisitos funcionais que também possuem essa característica. Como está fora do escopo deste artigo descrever esse tipo de paradigma, sugere-se aos leitores que quiserem se aprofundar no tema a leitura de material a respeito. No Brasil e na América Latina, um dos principais fóruns acadêmicos na área de aspectos é o LA-WASP (Latin-American Workshop on Aspect-oriented Software Development). No ano de 2008, esse evento contou com o painel Adoption of AOSD in Industry, em que renomados profissionais e pesquisadores da área discutiram sobre a adoção dos aspectos pela indústria. O painel (figura 2 participantes citados da esquerda para direita) contou com o professor Paulo Borba, UFPE, como moderador e com a participação de Flávia Raimone, da JBoss Brasil e desenvolvedora do JBoss AOP, com o professor Kevin Sullivan, da University of Virginia, e com Paulo Merson, do Software Engineering Institute (SEI), Universidade Carnegie Mellon. Houve certo consenso de que a adoção desse paradigma de programação pela indústria ainda é modesto, porém muitos projetos utilizam softwares que possuem o uso de aspectos encapsulados dentro de sua implementação. Um grande exemplo é o próprio servidor de aplicações JBoss. Este painel foi citado, pois uma das perguntas feitas aos participantes foi a respeito do que é necessário para que esse paradigma seja mais adotado pela indústria. Uma das respostas foi o suporte nativo à programação orientada a aspectos pela linguagem Java. Infelizmente, pela conversa com Alex Buckley, é possível perceber que isso é algo que ainda está longe de acontecer. Ao ser perguntado sobre esta possibilidade, a resposta de Alex foi que, embora os aspectos já sejam bastante maduros, ao colocá-los na linguagem, isto significaria que todos os desenvolvedores Java precisariam aprender sobre o assunto, desde desenvolvedores de dispositivos móveis até programadores de supercomputadores. Ele citou Bjarne Stroustrup (o desenvolvedor da linguagem C++), que há algum tempo falou sobre as propostas de melhorias que ele recebe e leva para o C++ International Working Group. Ele disse publicamente que, se uma proposta não é útil para pelo menos 200 mil desenvolvedores, esta proposta não será nem considerada. No contexto da linguagem Java, este número pode ser projetado para mais ou menos dois milhões de desenvolvedores. Por esta razão, tão raramente uma proposta de melhoria é aceita. 46

12 Outra questão que deve ser considerada é que hoje Java é ensinada em diversas universidades do mundo como primeira linguagem de programação. A adição desses novos conceitos nativamente na linguagem aumentaria sua complexidade e dificultaria seu aprendizado. Se para o paradigma orientado a objetos foram necessários diversos anos de sua adoção na indústria para o amadurecimento de certos conceitos, imagine para a orientação a aspectos que ainda colhe seus primeiros frutos de sua utilização com sucesso no mercado. Na academia, existem várias pesquisas sobre o assunto, que procuram, por exemplo, definir o significado dos chamados adendos (advices) e como expressar melhor os pontos de junção (joint points) de um aspecto. A incorporação dos aspectos de forma nativa, provavelmente iria frear pesquisas sobre novas formas de expressar aspectos, prendendo a linguagem Java àquela implementação em todas as versões subsequentes por questões de compatibilidade. De certa forma, ao adicionar uma nova funcionalidade, a linguagem está concordando em suportá-la para sempre. Existem diversas implementações de aspectos na linguagem Java, podendo ser citados como exemplos o AspectJ, o Spring AOP e o JBoss AOP. O AspectJ é uma das implementações mais populares e mais completas, que define uma nova sintaxe para aspectos, porém em sua última versão, também suporta o uso de anotações para algumas coisas. O Spring AOP utiliza a própria linguagem Java para as definições realizando configurações adicionais em seus arquivos XML ou utilizando anotações. Ainda existem diversas opções para os aspectos serem agregados às classes (processo conhecido como weaving), como em tempo de compilação, em tempo de carregamento e em tempo de execução. Que tipo de abordagem é mais adequada para a linguagem Java? Apesar da tecnologia de aspectos já ter amadurecido bastante nos últimos anos, será que a comunidade está preparada para escolher uma delas para ser incorporada à linguagem, abandonando as outras abordagens e tendo que suportar para sempre a que foi escolhida? Esse foi o tipo de indagação que Alex Buckley apresentou sobre o assunto em sua conversa com a revista. A implementação de aspectos dentro de uma linguagem como Java não é apenas uma adição pontual na linguagem como as outras funcionalidades apresentadas neste artigo, e sim uma mudança profunda que afetaria o sistema de tipos e a própria arquitetura da máquina virtual. Segundo Alex, adicionar aspectos, pontos de junção e adendos como tipos da linguagem é algo complicado, principalmente quando é preciso manter a compatibilidade com o código legado. Porém os fãs de aspectos não devem ficar decepcionados com a notícia, pois a máquina virtual Java está dando cada vez mais um suporte melhor a outras linguagens. Como foi citado, no Java 7 está se trabalhando para que a invocação de métodos de outras linguagens não-java tenham um desempenho similar ao das invocações nativas. O próprio AspectJ pode ser considerado uma linguagem que compila para bytecode e executa dentro da máquina virtual. Dessa forma, o fato de Java ainda não ter planos de suportar nativamente aspectos, não significa que não podemos utilizar aspectos com a linguagem Java, e sim que talvez ainda não seja a hora de uma implementação ser fixada e de todos os desenvolvedores precisarem aprender esses novos conceitos. Considerações finais As alterações realizadas na linguagem no Java 5 trouxeram diversas lições. Uma delas foi que evoluções na linguagem podem trazer diversos benefícios, como os tipos genéricos, que ajudaram na criação de um código mais seguro, e as anotações, que criaram diversas novas possibilidades através da adição de novas informações às classes. Outra lição foi que é preciso ter muito cuidado com essas alterações, para que elas sejam compatíveis com código já existente. Como foi dito na entrevista, a adição da palavra-chave 'enum' quebrou muitos códigos que utilizavam essa palavra como um identificador. Este artigo apresentou com exclusividade uma entrevista com Alex Buckley, que falou sobre sua experiência na evolução da linguagem Java e a respeito do que podemos esperar para o seu futuro. Também foram vistas as principais funcionalidades de linguagem que devem entrar no Java 7, assim como certa previsão sobre quando funcionalidades como closures e aspectos devem aparecer nativamente na linguagem. Apesar de Alex Buckley ter dito que uma linguagem é melhor quando ela possui menos funcionalidades, é possível perceber pelas respostas e pelas propostas de funcionalidades para o Java 7 que a linguagem não está no caminho da simplicidade. Em uma entrevista com James Gosling realizada por Paulo Silveira e Guilherme Silveira em um JavaOne foi possível perceber essa mesma tendência. As novas funcionalidades certamente são interessantes e permitem, por exemplo, a detecção prematura de defeitos e uma melhor modularização. Isso revela uma tendência em evoluir a linguagem na busca de uma maior segurança de código mesmo que isso torne a codificação mais complexa, o que acaba indo na direção oposta de outras linguagens que procuram cada vez mais a simplificação na busca de uma maior produtividade. Vale a pena lembrar que, neste momento, as funcionalidades apresentadas ainda são apenas propostas, sendo que algumas delas não possuem nem JSR ainda. Dessa forma, se você quer participar dessa evolução e dar sua opinião sobre como deve ser a implementação em cada uma delas, é só se envolver e dar sua contribuição. O futuro do Java, na verdade, está em nossas mãos! Referências edu/~flab/languages.html ght.html manual.pdf tation-design.pdf - 47

Lidando de Forma Eficiente com Validações Locais de Objetos

Lidando de Forma Eficiente com Validações Locais de Objetos Lidando de Forma Eficiente com Validações Locais de Objetos Aprenda a construir um mini-framework para validar objetos locais sem afetar a complexidade do código. Autor Paulo César M. N. A. Coutinho (pcmnac@gmail.com):

Leia mais

Erros, exceçõ. ções e asserçõ

Erros, exceçõ. ções e asserçõ Java 2 Standard Edition Erros, exceçõ ções e asserçõ ções Helder da Rocha www.argonavis.com.br 1 Controle de erros com Exceções Exceções são Erros de tempo de execução Objetos criados a partir de classes

Leia mais

Módulo 06 Desenho de Classes

Módulo 06 Desenho de Classes Módulo 06 Desenho de Classes Última Atualização: 13/06/2010 1 Objetivos Definir os conceitos de herança, polimorfismo, sobrecarga (overloading), sobreescrita(overriding) e invocação virtual de métodos.

Leia mais

Reuso com Herança a e Composiçã

Reuso com Herança a e Composiçã Java 2 Standard Edition Reuso com Herança a e Composiçã ção Helder da Rocha www.argonavis.com.br 1 Como aumentar as chances de reuso Separar as partes que podem mudar das partes que não mudam. Exemplo:

Leia mais

Aula 09 Introdução à Java. Disciplina: Fundamentos de Lógica e Algoritmos Prof. Bruno Gomes http://www.profbrunogomes.com.br/

Aula 09 Introdução à Java. Disciplina: Fundamentos de Lógica e Algoritmos Prof. Bruno Gomes http://www.profbrunogomes.com.br/ Aula 09 Introdução à Java Disciplina: Fundamentos de Lógica e Algoritmos Prof. Bruno Gomes http://www.profbrunogomes.com.br/ Agenda da Aula Java: Sintaxe; Tipos de Dados; Variáveis; Impressão de Dados.

Leia mais

Programação de Computadores - I. Profª Beatriz Profº Israel

Programação de Computadores - I. Profª Beatriz Profº Israel Programação de Computadores - I Profª Beatriz Profº Israel As 52 Palavras Reservadas O que são palavras reservadas São palavras que já existem na linguagem Java, e tem sua função já definida. NÃO podem

Leia mais

Os Sete Hábitos das Exceções Altamente Eficazes

Os Sete Hábitos das Exceções Altamente Eficazes c o l u n a Mundo OO Os Sete Hábitos das Exceções Altamente Eficazes Aprenda os bons hábitos na modelagem de erros de uma aplicação A modelagem no tratamento de erros de uma aplicação é uma atividade que

Leia mais

CURSO DE PROGRAMAÇÃO EM JAVA

CURSO DE PROGRAMAÇÃO EM JAVA CURSO DE PROGRAMAÇÃO EM JAVA Introdução para Iniciantes Prof. M.Sc. Daniel Calife Índice 1 - A programação e a Linguagem Java. 1.1 1.2 1.3 1.4 Linguagens de Programação Java JDK IDE 2 - Criando o primeiro

Leia mais

PROGRAMAÇÃO ORIENTADA A OBJETOS -TRATAMENTO DE EXCEÇÕES. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br

PROGRAMAÇÃO ORIENTADA A OBJETOS -TRATAMENTO DE EXCEÇÕES. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br PROGRAMAÇÃO ORIENTADA A OBJETOS -TRATAMENTO DE EXCEÇÕES Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 5. Tratamento de Exceções Introdução e conceitos Capturando exceção usando

Leia mais

Java 2 Standard Edition Como criar classes e objetos

Java 2 Standard Edition Como criar classes e objetos Java 2 Standard Edition Como criar classes e objetos Helder da Rocha www.argonavis.com.br 1 Assuntos abordados Este módulo explora detalhes da construção de classes e objetos Construtores Implicações da

Leia mais

Linguagem de Programação JAVA. Técnico em Informática Professora Michelle Nery

Linguagem de Programação JAVA. Técnico em Informática Professora Michelle Nery Linguagem de Programação JAVA Técnico em Informática Professora Michelle Nery Agenda Regras paravariáveis Identificadores Válidos Convenção de Nomenclatura Palavras-chaves em Java Tipos de Variáveis em

Leia mais

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP 1) Introdução Programação Orientada a Objetos é um paradigma de programação bastante antigo. Entretanto somente nos últimos anos foi aceito realmente

Leia mais

Computação II Orientação a Objetos

Computação II Orientação a Objetos Computação II Orientação a Objetos Fabio Mascarenhas - 2014.1 http://www.dcc.ufrj.br/~fabiom/java Classes abstratas Até agora, usamos interfaces toda vez que queríamos representar algum conceito abstrato

Leia mais

Programação Orientada a Objetos em java. Polimorfismo

Programação Orientada a Objetos em java. Polimorfismo Programação Orientada a Objetos em java Polimorfismo Polimorfismo Uma característica muito importante em sistemas orientados a objetos Termo proveniente do grego, e significa muitas formas Em POO, significa

Leia mais

EMENTA DO CURSO. Tópicos:

EMENTA DO CURSO. Tópicos: EMENTA DO CURSO O Curso Preparatório para a Certificação Oracle Certified Professional, Java SE 6 Programmer (Java Básico) será dividido em 2 módulos e deverá ter os seguintes objetivos e conter os seguintes

Leia mais

FBV - Linguagem de Programação II. Um pouco sobre Java

FBV - Linguagem de Programação II. Um pouco sobre Java FBV - Linguagem de Programação II Um pouco sobre Java História 1992: um grupo de engenheiros da Sun Microsystems desenvolve uma linguagem para pequenos dispositivos, batizada de Oak Desenvolvida com base

Leia mais

Orientação a Objetos em Java. Leonardo Gresta Paulino Murta leomurta@ic.uff.br

Orientação a Objetos em Java. Leonardo Gresta Paulino Murta leomurta@ic.uff.br Orientação a Objetos em Java Leonardo Gresta Paulino Murta leomurta@ic.uff.br Agenda Introdução; Orientação a Objetos; Orientação a Objetos em Java; Leonardo Murta Orientação a Objetos em Java 2 Agosto/2007

Leia mais

O uso de exceções permite separar a detecção da ocorrência de uma situação excepcional do seu tratamento, ao se programar um método em Java.

O uso de exceções permite separar a detecção da ocorrência de uma situação excepcional do seu tratamento, ao se programar um método em Java. Exceções em Java Miguel Jonathan DCC/IM/UFRJ (rev. abril de 2011) Resumo dos conceitos e regras gerais do uso de exceções em Java O uso de exceções permite separar a detecção da ocorrência de uma situação

Leia mais

Curso Adonai QUESTÕES Disciplina Linguagem JAVA

Curso Adonai QUESTÕES Disciplina Linguagem JAVA 1) Qual será o valor da string c, caso o programa rode com a seguinte linha de comando? > java Teste um dois tres public class Teste { public static void main(string[] args) { String a = args[0]; String

Leia mais

Prof. Marcelo Heitor Teixeira marceloheitor.com. Java Exceções e Finalizações

Prof. Marcelo Heitor Teixeira marceloheitor.com. Java Exceções e Finalizações Prof. Marcelo Heitor Teixeira marceloheitor.com Java Exceções e Finalizações # Exceções em Java # Hierarquia de Classes # Lançando, Declarando e Capturando # Classes de Exceções Personalizadas # Entendendo

Leia mais

Especialização em desenvolvimento para web com interfaces ricas. Tratamento de exceções em Java Prof. Fabrízzio A. A. M. N. Soares

Especialização em desenvolvimento para web com interfaces ricas. Tratamento de exceções em Java Prof. Fabrízzio A. A. M. N. Soares Especialização em desenvolvimento para web com interfaces ricas Tratamento de exceções em Java Prof. Fabrízzio A. A. M. N. Soares Objetivos Conceito de exceções Tratar exceções pelo uso de try, catch e

Leia mais

Aula 2. Objetivos. Encapsulamento na linguagem Java; Utilizando a referência this.

Aula 2. Objetivos. Encapsulamento na linguagem Java; Utilizando a referência this. Aula 2 Objetivos Encapsulamento na linguagem Java; Utilizando a referência this. Encapsulamento, data hiding é um conceito bastante importante em orientação a objetos. É utilizado para restringir o acesso

Leia mais

NOVIDADES DO JAVA PARA PROGRAMADORES C

NOVIDADES DO JAVA PARA PROGRAMADORES C PROGRAMAÇÃO SERVIDOR EM SISTEMAS WEB NOVIDADES DO JAVA PARA PROGRAMADORES C Prof. Dr. Daniel Caetano 2012-1 Objetivos Apresentar o Conceito de Classes e Objetos Capacitar para a criação de objetos simples

Leia mais

Programação Orientada a Objetos

Programação Orientada a Objetos Programação Orientada a Objetos Engenharia da Computação Professor: Rosalvo Ferreira de Oliveira Neto Dados Pessoais Rosalvo Ferreira de Oliveira Neto MSc. em ciência da computação (UFPE) rosalvo.oliveira@univasf.edu.br

Leia mais

Guia de Fatores de Qualidade de OO e Java

Guia de Fatores de Qualidade de OO e Java Qualiti Software Processes Guia de Fatores de Qualidade de OO e Java Versã o 1.0 Este documento só pode ser utilizado para fins educacionais, no Centro de Informática da Universidade Federal de Pernambuco.

Leia mais

Java Como Programar, 8/E

Java Como Programar, 8/E Capítulo 2 Introdução aos aplicativos Java Java Como Programar, 8/E (C) 2010 Pearson Education, Inc. Todos os 2.1 Introdução Programação de aplicativo Java. Utilize as ferramentas do JDK para compilar

Leia mais

Sobre o Professor Dr. Sylvio Barbon Junior

Sobre o Professor Dr. Sylvio Barbon Junior 5COP088 Laboratório de Programação Aula 1 Java Prof. Dr. Sylvio Barbon Junior Sylvio Barbon Jr barbon@uel.br 1 Sobre o Professor Dr. Sylvio Barbon Junior Formação: Ciência e Engenharia da Computação (2005

Leia mais

Java. Marcio de Carvalho Victorino www.dominandoti.eng.br

Java. Marcio de Carvalho Victorino www.dominandoti.eng.br Java Marcio de Carvalho Victorino www.dominandoti.eng.br 3. Considere as instruções Java abaixo: int cont1 = 3; int cont2 = 2; int cont3 = 1; cont1 += cont3++; cont1 -= --cont2; cont3 = cont2++; Após a

Leia mais

1.6. Tratamento de Exceções

1.6. Tratamento de Exceções Paradigmas de Linguagens I 1 1.6. Tratamento de Exceções Uma exceção denota um comportamento anormal, indesejado, que ocorre raramente e requer alguma ação imediata em uma parte do programa [GHE 97, DER

Leia mais

Criando documentação com javadoc

Criando documentação com javadoc H Criando documentação com javadoc H.1 Introdução Neste apêndice, fornecemos uma introdução a javadoc ferramenta utilizada para criar arquivos HTML que documentam o código Java. Essa ferramenta é usada

Leia mais

Aula 10: Análise Dinâmica - 1a. Parte

Aula 10: Análise Dinâmica - 1a. Parte Aula 10: Análise Dinâmica - 1a. Parte A melhor forma de garantir a qualidade do software que você constrói é projetando-o cuidadosamente desde o início. Desta forma, as partes se encaixarão mais perfeitamente,

Leia mais

Curso Java Starter. www.t2ti.com 1

Curso Java Starter. www.t2ti.com 1 1 Apresentação O Curso Java Starter foi projetado com o objetivo de ajudar àquelas pessoas que têm uma base de lógica de programação e desejam entrar no mercado de trabalho sabendo Java, A estrutura do

Leia mais

Introdução a Linguagem

Introdução a Linguagem Introdução a Linguagem Prof. Edwar Saliba Júnior Fevereiro de 2011 Unidade 03 Introdução a Linguagem Java 1 Conteúdo Máquina Virtual (JVM) Histórico de Java Case Sensitive Tipos Primitivos Tipo String

Leia mais

Linguagens de. Aula 02. Profa Cristiane Koehler cristiane.koehler@canoas.ifrs.edu.br

Linguagens de. Aula 02. Profa Cristiane Koehler cristiane.koehler@canoas.ifrs.edu.br Linguagens de Programação III Aula 02 Profa Cristiane Koehler cristiane.koehler@canoas.ifrs.edu.br Linguagens de Programação Técnica de comunicação padronizada para enviar instruções a um computador. Assim

Leia mais

Memory Leak em Java?

Memory Leak em Java? 1 Memory Leak em Java? Saiba como memory leaks se manifestam em Java e como evitá-los Sobre o Autor Carlos Eduardo G. Tosin (carlos@tosin.com.br) é formado em Ciência da Computação pela PUC-PR, pós-graduado

Leia mais

Curso Java Starter. www.t2ti.com 1

Curso Java Starter. www.t2ti.com 1 1 2 Apresentação O Curso Java Starter foi projetado com o objetivo de ajudar àquelas pessoas que têm uma base de lógica de programação e desejam entrar no mercado de trabalho sabendo Java, A estrutura

Leia mais

JavaScript 2.0X 1.0 3.0X 1.1 4.0 4.05 1.2 4.06 4.61 1.3 5.0 1.4 6.0 1.5

JavaScript 2.0X 1.0 3.0X 1.1 4.0 4.05 1.2 4.06 4.61 1.3 5.0 1.4 6.0 1.5 JavaScript Diego R. Frank, Leonardo Seibt FIT Faculdades de Informática de Taquara Fundação Educacional Encosta Inferior do Nordeste Av. Oscar Martins Rangel, 4500 Taquara RS Brasil difrank@terra.com.br,

Leia mais

CONCEITOS DE LINGUAGEM DE PROGRAMAÇÃO CARACTERÍSTICAS. João Gabriel Ganem Barbosa

CONCEITOS DE LINGUAGEM DE PROGRAMAÇÃO CARACTERÍSTICAS. João Gabriel Ganem Barbosa CONCEITOS DE LINGUAGEM DE PROGRAMAÇÃO CARACTERÍSTICAS João Gabriel Ganem Barbosa Sumário Motivação História Linha do Tempo Divisão Conceitos Paradigmas Geração Tipos de Dados Operadores Estruturada vs

Leia mais

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE ALAGOAS CURSO TECNICO EM INFORMATICA DISCIPLINA:

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE ALAGOAS CURSO TECNICO EM INFORMATICA DISCIPLINA: INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE ALAGOAS CURSO TECNICO EM INFORMATICA DISCIPLINA: PROGRAMAÇÃO ORIENTADA A OBJETOS PROFESSOR: REINALDO GOMES ASSUNTO: REVISÃO DA INTRODUÇÃO A ORIENTAÇÃO

Leia mais

Anotações Próximas ao Domínio da Sua Aplicação

Anotações Próximas ao Domínio da Sua Aplicação Atualmente, a comunidade de desenvolvimento de software entende que, ao se desenvolver software, a verdadeira complexidade está, na maioria das vezes, no domínio onde a aplicação se encaixa. A intenção

Leia mais

JAVA. Introdução. Marcio de Carvalho Victorino. Page 1 1/40 2/40

JAVA. Introdução. Marcio de Carvalho Victorino. Page 1 1/40 2/40 JAVA Marcio de Carvalho Victorino 1/40 Introdução 2/40 Page 1 Programação OO Elementos do modelo OO: Abstração: é o processo de abstrair as características essenciais de um objeto real. O conjunto de características

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 10 Persistência de Dados

Leia mais

Prof. Esp. Adriano Carvalho

Prof. Esp. Adriano Carvalho Prof. Esp. Adriano Carvalho Um arquivo contendo uma sequência de comandos em uma linguagem de programação especifica Esses comandosrespeitam regras de como serem escritos e quais são as palavras que podem

Leia mais

Seminário - C# DSO II. Desenvolvimento de Sistemas Orientados a Objetos 2. Equipe: Diorges, Leonardo, Luís Fernando, Ronaldo

Seminário - C# DSO II. Desenvolvimento de Sistemas Orientados a Objetos 2. Equipe: Diorges, Leonardo, Luís Fernando, Ronaldo Seminário - C# DSO II Desenvolvimento de Sistemas Orientados a Objetos 2 Equipe: Diorges, Leonardo, Luís Fernando, Ronaldo Roteiro Breve Histórico Plataforma.NET Características da Linguagem Sintaxe Versões

Leia mais

Lógica de Programação

Lógica de Programação Lógica de Programação Unidade 4 Ambiente de desenvolvimento Java QI ESCOLAS E FACULDADES Curso Técnico em Informática SUMÁRIO A LINGUAGEM JAVA... 3 JVM, JRE, JDK... 3 BYTECODE... 3 PREPARANDO O AMBIENTE

Leia mais

Treinar - Cursos e Treinamentos C# Módulo I. Carga horária: 32 Horas

Treinar - Cursos e Treinamentos C# Módulo I. Carga horária: 32 Horas Treinar - Cursos e Treinamentos C# Módulo I Carga horária: 32 Horas Pré-requisito: Para que os alunos possam aproveitar este treinamento ao máximo, é importante que eles tenham participado dos treinamentos

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ

UNIVERSIDADE FEDERAL DO PARANÁ CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. PROFESSOR: Andrey DISCIPLINA: Técnicas Alternativas de Programação AULA: 02 APRESENTAÇÃO: Apresentação; conceitos básicos da linguagem java; estrutura

Leia mais

3 Classes e instanciação de objectos (em Java)

3 Classes e instanciação de objectos (em Java) 3 Classes e instanciação de objectos (em Java) Suponhamos que queremos criar uma classe que especifique a estrutura e o comportamento de objectos do tipo Contador. As instâncias da classe Contador devem

Leia mais

Revisão OO Básico. Orientação a Objetos em Java

Revisão OO Básico. Orientação a Objetos em Java Revisão OO Básico Orientação a Objetos em Java Grupo de Linguagens de Programação Departamento de Informática PUC-Rio Nomenclatura A unidade básica de programação em linguagens orientadas a objetos é a

Leia mais

Linguagens de programação

Linguagens de programação Prof. André Backes Linguagens de programação Linguagem de Máquina Computador entende apenas pulsos elétricos Presença ou não de pulso 1 ou 0 Tudo no computador deve ser descrito em termos de 1 s ou 0 s

Leia mais

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de:

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de: i Sumário 1 Introdução 1 1.1 Linguagens....................................... 1 1.2 O que é um Compilador?................................ 2 1.3 Processadores de Programas: Compiladores, Interpretadores

Leia mais

Escola Superior de Gestão e Tecnologia. Tratamento de Exceções

Escola Superior de Gestão e Tecnologia. Tratamento de Exceções Escola Superior de Gestão e Tecnologia Tratamento de Exceções Objetivos Compreender como o tratamento de exceção e de erro funciona. Como u4lizar try, throw e catch para detectar, indicar e tratar exceções,

Leia mais

Paradigmas da Programação PPROG. Linguagem JAVA. Interfaces. (Livro Big Java, Late Objects Capítulo 9) Nelson Freire (ISEP DEI-PPROG 2013/14) 1/33

Paradigmas da Programação PPROG. Linguagem JAVA. Interfaces. (Livro Big Java, Late Objects Capítulo 9) Nelson Freire (ISEP DEI-PPROG 2013/14) 1/33 PPROG Paradigmas da Programação Linguagem JAVA Interfaces (Livro Big Java, Late Objects Capítulo 9) Nelson Freire (ISEP DEI-PPROG 2013/14) 1/33 PPROG Motivação para usar Interfaces Definição de Interface

Leia mais

Programação de Computadores II: Java. / NT Editora. -- Brasília: 2014. 82p. : il. ; 21,0 X 29,7 cm.

Programação de Computadores II: Java. / NT Editora. -- Brasília: 2014. 82p. : il. ; 21,0 X 29,7 cm. Autor José Jesse Gonçalves Graduado em Licenciatura em Matemática pela Universidade Estadual de São Paulo - UNESP, de Presidente Prudente (1995), com especialização em Análise de Sistemas (1999) e mestrado

Leia mais

Linguagem de Programação Visual

Linguagem de Programação Visual Linguagem de Programação Visual Unidade 1 Ambiente de desenvolvimento Curso Técnico em Informática SUMÁRIO INTRODUÇÃO... 3 SOBRE O JAVA... 3 AMBIENTE DE DESENVOLVIMENTO... 5 RECURSOS DA FERRAMENTA NETBEANS...

Leia mais

Laboratório de Programação. Aula 13 Java 5COP088. Aula 13 Genéricos e Conjuntos Java Prof. Dr. Sylvio Barbon Junior. Sylvio Barbon Jr barbon@uel.

Laboratório de Programação. Aula 13 Java 5COP088. Aula 13 Genéricos e Conjuntos Java Prof. Dr. Sylvio Barbon Junior. Sylvio Barbon Jr barbon@uel. 5COP088 Laboratório de Programação Aula 13 Genéricos e Conjuntos Java Prof. Dr. Sylvio Barbon Junior 1 Sumário: 1) Métodos hashcode(), equals() e tostring(); 2) Conjuntos; 3) Genéricos; 4) Resumo. 2 1)

Leia mais

Programação Java. com Ênfase em Orientação a Objetos. Douglas Rocha Mendes. Novatec

Programação Java. com Ênfase em Orientação a Objetos. Douglas Rocha Mendes. Novatec Programação Java com Ênfase em Orientação a Objetos Douglas Rocha Mendes Novatec Sumário Agradecimentos... 13 Sobre o autor... 14 Prefácio... 15 Capítulo 1 Introdução à linguagem Java... 16 1.1 Histórico

Leia mais

A Linguagem Java. Alberto Costa Neto DComp - UFS

A Linguagem Java. Alberto Costa Neto DComp - UFS A Linguagem Java Alberto Costa Neto DComp - UFS 1 Roteiro Comentários Variáveis Tipos Primitivos de Dados Casting Comandos de Entrada e Saída Operadores Constantes 2 Comentários /** Classe para impressão

Leia mais

2 Orientação a objetos na prática

2 Orientação a objetos na prática 2 Orientação a objetos na prática Aula 04 Sumário Capítulo 1 Introdução e conceitos básicos 1.4 Orientação a Objetos 1.4.1 Classe 1.4.2 Objetos 1.4.3 Métodos e atributos 1.4.4 Encapsulamento 1.4.5 Métodos

Leia mais

Algoritmos em Javascript

Algoritmos em Javascript Algoritmos em Javascript Sumário Algoritmos 1 O que é um programa? 1 Entrada e Saída de Dados 3 Programando 4 O que é necessário para programar 4 em JavaScript? Variáveis 5 Tipos de Variáveis 6 Arrays

Leia mais

Curso. Linguagem Java

Curso. Linguagem Java Seja Bem Vindo! Curso Linguagem Java Carga horária: 40hs 1 Dicas importantes Nunca se esqueça de que o objetivo central é aprender o conteúdo, e não apenas terminar o curso. Qualquer um termina, só os

Leia mais

Porque tornar-se um profissional certificado? Por que vale a pena investir na carreira Java?

Porque tornar-se um profissional certificado? Por que vale a pena investir na carreira Java? Sumário Porque tornar-se um profissional certificado?...3 Por que vale a pena investir na carreira Java?...3 Diferenciais da DataSun...4 Sobre o treinamento "Programador Java 6"...4 Tópicos mais explorados

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Marcelo Lobosco DCC/UFJF Comunicação em Sistemas Distribuídos Aula 06 Agenda Modelo Cliente-Servidor (cont.) Invocação Remota de Método (Remote Method Invocation RMI) Visão Geral

Leia mais

Implementação de Jogo de Damas em Python Orientado a Objetos e em Python Funcional

Implementação de Jogo de Damas em Python Orientado a Objetos e em Python Funcional Implementação de Jogo de Damas em Python Orientado a Objetos e em Python Funcional Cristiano Medeiros Dalbem - 173362 INF01121 Modelos de Linguagens de Programação Instituto de Informática Universidade

Leia mais

Padrões de Codificação Java

Padrões de Codificação Java Padrões de Codificação Java João Carlos Pinheiro jcpinheiro@cefet-ma.br Versão: 1.0 Última Atualização: Março / 2005 1 Objetivos Apresentar os padrões de codificação Java da SUN 2 Introdução Um padrão

Leia mais

DEFINIÇÃO DE MÉTODOS

DEFINIÇÃO DE MÉTODOS Cursos: Análise, Ciência da Computação e Sistemas de Informação Programação I - Prof. Aníbal Notas de aula 2 DEFINIÇÃO DE MÉTODOS Todo o processamento que um programa Java faz está definido dentro dos

Leia mais

Curso de Linguagem C

Curso de Linguagem C Curso de Linguagem C 1 Aula 1 - INTRODUÇÃO...4 AULA 2 - Primeiros Passos...5 O C é "Case Sensitive"...5 Dois Primeiros Programas...6 Introdução às Funções...7 Introdução Básica às Entradas e Saídas...

Leia mais

CURSO DESENVOLVEDOR JAVA Edição 2009

CURSO DESENVOLVEDOR JAVA Edição 2009 CURSO DESENVOLVEDOR JAVA Edição 2009 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos e com o uso

Leia mais

INTRODUÇÃO AO C++ SISTEMAS DE INFORMAÇÃO DR. EDNALDO B. PIZZOLATO

INTRODUÇÃO AO C++ SISTEMAS DE INFORMAÇÃO DR. EDNALDO B. PIZZOLATO INTRODUÇÃO AO C++ SISTEMAS DE INFORMAÇÃO DR. EDNALDO B. PIZZOLATO Tópicos Estrutura Básica B de Programas C e C++ Tipos de Dados Variáveis Strings Entrada e Saída de Dados no C e C++ INTRODUÇÃO O C++ aceita

Leia mais

Aspectos para Leigos. Programação Orientada a. Aprenda a dar os primeiros passos no paradigma orientado a aspectos usando o AspectJ com anotações.

Aspectos para Leigos. Programação Orientada a. Aprenda a dar os primeiros passos no paradigma orientado a aspectos usando o AspectJ com anotações. Eduardo Guerra (guerra@mundoj.com.br / Twitter @emguerra) é desenvolvedor de frameworks, pesquisador em design de software, editor-chefe da revista MundoJ e professor do ITA, onde concluiu sua graduação,

Leia mais

Evolução do Design através de Testes e o TDD

Evolução do Design através de Testes e o TDD c a p a Lucas Souza (lucas.souza@caelum.com.br): é bacharel em Engenharia da Computação pela Universidade de Ribeirão Preto, possui a certificação SCJP e trabalha com Java há 4 anos. Atualmente é desenvolvedor

Leia mais

OOP - Java. Artur Duque Rossi Mestrado em Modelagem Computacional Universidade Federal de Juiz de Fora

OOP - Java. Artur Duque Rossi Mestrado em Modelagem Computacional Universidade Federal de Juiz de Fora OOP - Java Artur Duque Rossi Mestrado em Modelagem Computacional Universidade Federal de Juiz de Fora 1 Sumário Java Aviso! História do Java Programação Orientada à Objetos Os quatro pilares da OOP Abstração

Leia mais

Dois clientes com a mesma data de pagamento não podem compartilhar instâncias

Dois clientes com a mesma data de pagamento não podem compartilhar instâncias Capítulo 3. Tópicos de Orientação a Objetos correr o risco de cair na armadilha da quebra de encapsulamento e alto acoplamento. Repare que, desta forma, o acoplamento é bem menor, nenhuma das classes precisa

Leia mais

BCC221 Programação Orientada a Objetos. Prof. Marco Antonio M. Carvalho 2014/2

BCC221 Programação Orientada a Objetos. Prof. Marco Antonio M. Carvalho 2014/2 BCC221 Programação Orientada a Objetos Prof. Marco Antonio M. Carvalho 2014/2 Site da disciplina: http://www.decom.ufop.br/marco/ Moodle: www.decom.ufop.br/moodle Lista de e- mails: bcc221- decom@googlegroups.com

Leia mais

4 Avaliação do Código Gerado

4 Avaliação do Código Gerado Referencial Teórico 4 Avaliação do Código Gerado Nós fizemos alguns exemplos para avaliar a eficiência da especificação proposta, tanto em termos de velocidade de execução quanto de diminuição do tamanho

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

Leia mais

Programação Avançada

Programação Avançada Índice 1.1 - Introdução História A plataforma Java 1.2 - Conceitos Fundamentais na programação por objectos Objectos Encapsulamento Classes Herança Polimorfismo Interfaces Pacotes 1/24 1.1 Introdução 1.1

Leia mais

Coleções Avançadas. Programação Orientada a Objetos Java. Prof. Anselmo Cardoso Paiva Prof. Geraldo Braz Junior

Coleções Avançadas. Programação Orientada a Objetos Java. Prof. Anselmo Cardoso Paiva Prof. Geraldo Braz Junior Coleções Avançadas Programação Orientada a Objetos Java Prof. Anselmo Cardoso Paiva Prof. Geraldo Braz Junior Objetivos Aprender como o conceito de coleção pode ser expresso de forma genérica Examinar

Leia mais

Coleções. Page 1. Coleções. Prof. Anderson Augustinho Uniandrade

Coleções. Page 1. Coleções. Prof. Anderson Augustinho Uniandrade Page 1 podem ser comparadas com arrays, visto que também apresentam a capacidade de armazenar referências para vários objetos. Entretanto, as coleções apresentam uma gama de funcionalidades bem maior do

Leia mais

Sintaxe Geral Tipos de Dados. Prof. Angelo Augusto Frozza, M.Sc.

Sintaxe Geral Tipos de Dados. Prof. Angelo Augusto Frozza, M.Sc. Sintaxe Geral Tipos de Dados Comentários Comentários: De linha: // comentário 1 // comentário 2 De bloco: /* linha 1 linha 2 linha n */ De documentação: /** linha1 * linha2 */ Programa Exemplo: ExemploComentario.java

Leia mais

Uma Introdução à Arquitetura CORBA. O Object Request Broker (ORB)

Uma Introdução à Arquitetura CORBA. O Object Request Broker (ORB) Uma Introdução à Arquitetura Francisco C. R. Reverbel 1 Copyright 1998-2006 Francisco Reverbel O Object Request Broker (ORB) Via de comunicação entre objetos (object bus), na arquitetura do OMG Definido

Leia mais

Programação por Objectos. Java

Programação por Objectos. Java Programação por Objectos Java Parte 2: Classes e objectos LEEC@IST Java 1/24 Classes (1) Sintaxe Qualif* class Ident [ extends IdentC] [ implements IdentI [,IdentI]* ] { [ Atributos Métodos ]* Qualif:

Leia mais

Programação Na Web. Linguagem Java Parte II. break com o nome do bloco. Sintaxe. Nome do bloco. Termina o bloco. António Gonçalves ...

Programação Na Web. Linguagem Java Parte II. break com o nome do bloco. Sintaxe. Nome do bloco. Termina o bloco. António Gonçalves ... Programação Na Web Linguagem Java Parte II Sintaxe António Gonçalves break com o nome do bloco Nome do bloco Termina o bloco class class Matrix Matrix { private private int[][] int[][] mat; mat; public

Leia mais

PROJETO PEDAGÓGICO DE CURSOS

PROJETO PEDAGÓGICO DE CURSOS 1 de 6 PROJETO PEDAGÓGICO DE CURSOS BURITREINAMENTOS MANAUS-AM NOVEMBRO / 2014 2 de 6 PACOTES DE TREINAMENTOS BURITECH A Buritech desenvolveu um grupo de pacotes de treinamentos, aqui chamados de BuriPacks,

Leia mais

Capítulo 5 Reuso de Classes

Capítulo 5 Reuso de Classes Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Desenvolvimento Orientado a Objetos com Java Capítulo 5 Reuso de Classes

Leia mais

Introdução. à Linguagem JAVA. Prof. Dr. Jesus, Edison O. Instituto de Matemática e Computação. Laboratório de Visão Computacional

Introdução. à Linguagem JAVA. Prof. Dr. Jesus, Edison O. Instituto de Matemática e Computação. Laboratório de Visão Computacional Introdução à Linguagem JAVA Prof. Dr. Jesus, Edison O. Instituto de Matemática e Computação Laboratório de Visão Computacional Vantagens do Java Independência de plataforma; Sintaxe semelhante às linguagens

Leia mais

INTRODUÇÃO 12. DOCUMENTAÇÃO INTRODUÇÃO INTRODUÇÃO

INTRODUÇÃO 12. DOCUMENTAÇÃO INTRODUÇÃO INTRODUÇÃO INTRODUÇÃO 12. DOCUMENTAÇÃO Na plataforma Java SE 7, há cerca de 4000 classes e interfaces disponíveis para utilizarmos em nossas aplicações Podemos visualizar a documentação dessas classes e interfaces

Leia mais

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma

Leia mais

Paradigmas de Programação

Paradigmas de Programação Paradigmas de Programação Tipos de Dados Aula 5 Prof.: Edilberto M. Silva http://www.edilms.eti.br Prof. Edilberto Silva / edilms.eti.br Tipos de Dados Sistema de tipos Tipos de Dados e Domínios Métodos

Leia mais

Java Básico. Classes Abstratas, Exceções e Interfaces Prof. Fernando Vanini Ic-Unicamp

Java Básico. Classes Abstratas, Exceções e Interfaces Prof. Fernando Vanini Ic-Unicamp Java Básico Classes Abstratas, Exceções e Interfaces Prof. Fernando Vanini Ic-Unicamp Classes Abstratas construção de uma classe abstrata construção de classes derivadas Classes e Herança Uma classe define

Leia mais

Capítulo 3. Programação por objectos em Java

Capítulo 3. Programação por objectos em Java Capítulo 3. Programação por objectos em Java 1/46 Índice Indice 3.1 - Qualificadores de visualização 3.2 - Classe 3.3 - Objecto 3.4 - Métodos 3.5 - Herança 3.6 - Reescrita de métodos 3.7 - Classes abstractas

Leia mais

Auditando persistência com JPA

Auditando persistência com JPA a r t i g o Em ambientes corporativos, a auditoria sobre as operações de banco de dados é importantíssima, quando não, indispensável. Essa importância surge a partir de um conjunto de necessidades, como:

Leia mais

Lição 9 Trabalhando com bibliotecas de classes

Lição 9 Trabalhando com bibliotecas de classes Lição 9 Trabalhando com bibliotecas de classes Introdução à Programação I 1 Objetivos Ao final da lição, o estudante deverá estar apto a: Explicar o que é programação orientada a objetos e alguns de seus

Leia mais

Lista de Contas: Assinatura. Lista de Contas. Listas de Contas: Descrição. Listas de Contas: Descrição. Listas de Contas: Descrição

Lista de Contas: Assinatura. Lista de Contas. Listas de Contas: Descrição. Listas de Contas: Descrição. Listas de Contas: Descrição Lista de Contas Lista de Contas: Assinatura null Quais são os métodos necessários? class ListaDeContas { void inserir (Conta c) { void retirar (Conta c) { Conta procurar (String num) { Listas de Contas:

Leia mais

Primeiro programa em Java (compilação e execução)

Primeiro programa em Java (compilação e execução) Universidade Federal do ABC Disciplina: Linguagens de Programação (BC-0501) Assunto: Primeiro programa em Java (compilação e execução) Primeiro programa em Java (compilação e execução) Introdução Este

Leia mais

Programação com Objectos. Processamento de Dados I. 5. Excepções

Programação com Objectos. Processamento de Dados I. 5. Excepções Programação com Objectos Processamento de Dados I 5. Excepções 1 O que é uma excepção? Tratamento de excepções: Try e Catch Lançamento de excepções: Throw e Throws Classes de excepção Programação com Objectos

Leia mais

Programação Orientada a Objetos em Java. Herança

Programação Orientada a Objetos em Java. Herança Universidade Federal do Amazonas Departamento de Ciência da Computação IEC481 Projeto de Programas Programação Orientada a Objetos em Java Herança Professor: César Melo Slides baseados em materiais preparados

Leia mais