Novidades no NetBeans IDE da Apache para Java 9

A Apache Software Foundation lançou uma versão beta do seu ambiente de desenvolvimento NetBeans Version 9.0, que inclui as primeiras capacidades existentes no JDK 9. Suporta, por exemplo, o Java Module System introduzido com o Java 9 em Setembro de 2017.

As principais novidades:

‒ um modo “ModulePath” para capacitar o ambiente para o uso de módulos, além de suportar a opção “classpath” de longa data para o “runtime” na busca de ficheiros de classe e recursos;

‒ a capacidade de um projecto típico do NetBeans pode servir como módulo de Java Development Kit 9 através de um ficheiro “module-info.java” no pacote base;

‒ suporte em módulos para o ciclo completo de edição, compilação, depuração e análise;

‒ a capacidade de mostrar dependências do módulo no IDE;

‒ uma interface de utilizador, como console para as ferramentas Java Shell (JShell), REPL (“read-eval-print-loop”), que podem ser suportadas com a configuração do projeto do utilizador;

‒ adição de ações ao instrumentos análise da Java para expandir e colapsar nós em resultados de tabela de árvores.

‒ “Popups” redimensionáveis ​​das ferramentas de análise, para facilitar a manipulação de nomes longos de classe ou método;

‒ Suporte para a PHP 7.1, incluindo visibilidade constante sobre classes, a detecção múltipla de exceções e de tipos anuláveis;

‒ Para o desenvolvimento do PHP 7.0, um instrumento de análise lexical sensível ao contexto;

‒ Também para PHP, o editor sugere tipos de retorno vazio e métodos não abstractos incorretos;

‒ O depurador C / C ++ para depuração “dbx” nativa;

‒ Suporte no editor C / C ++ para a ferramenta de formatação para formato Clang;

‒ Também para o desenvolvimento de C / C ++, uma versão experimental de diagnóstico baseado em Clank, que mostra o caminho de erro de um problema.

O NetBeans 9.0 também traz um novo projeto, o Java Modular Project, para o desenvolvimento de vários módulos JDK 9 em projeto baseado em Ant. Com isso, os projetos de aplicações em Java podem ser empacotados numa imagem JLink para distribuição da aplicação e dos módulos necessários.

Fonte: ComputerWorld

Apache Geronimo 3.0 Suporta Java 7

  Versão 3.0 do servidor de aplicativos Java de código aberto Apache Geronimo foi lançado hoje, com suporte oficial para a versão 7 da linguagem de programação. O servidor foi totalmente certificado para Java EE 6 desde novembro de 2011, e a versão 4.3 do padrão da indústria OSGi agora também é suportada. Os desenvolvedores atualizaram componentes das diversas outras tecnologias Apache, como a aplicação Bval Bean Validation e o banco de dados Derby.

  Atualmente, a nova versão do Geronimo só está disponível em pacotes que usam o servlet container TomCat, com o TomCat 7.0.27 sendo a versão utilizada. Enquanto isso, assemblies Jetty são planejados para seguir em futuras versões "bugfix" devido aos testes parecem terem tido sucesso até agora. O mesmo se aplica ao suporte para IPv6 e ao plugin Geronimo para o Eclipse Indigo, que os desenvolvedores também pretendem implementar em versões posteriores (bugfix).

Fonte: Under-Linux

Apache TomEE 1.0 Final: Java EE otimizado para a nuvem

A Fundação Apache anunciou em final de abril a liberação do TomEE 1.0 final. O Apache TomEE (se pronuncia "Tommy") é a fusão do popular container web Tomcat com outros projetos Apache. O projeto é coordenado pela comunidade OpenEJB, resultando em um servidor de aplicações certificado no Java EE 6 Web Profile.

Em comparação com as versões beta disponibilizadas anteriormente, o TomEE 1.0 final tem um tempo de inicialização e consumo de memória bastante reduzidos, provavelmente os menores de qualquer servidor Java EE. As melhorias foram obtidas otimizando-se os classloaders e o processamento de anotações e TLDs (descritores para Tag Libraries do JSP). Aplicações reais como o Confluence e o Lift foram usadas para se determinar quais otimizações teriam o maior efeito.

Outras novidades da versão final incluem suporte ao Arquiliam e um plugin experimental para provisionamento direto de um repositório Maven.
TomEE versus Tomcat

A versão final do TomEE 1.0 é baseada no Tomcat 7.0.27, que entre outras coisas acrescentou ao container web suporte a WebSockets.

Um dos objetivos do projeto é que o TomEE pareça, para todos os propósitos práticos, ser apenas um servidor Tomcat contendo APIs adicionais. Uma instalação do Tomcat 7.0.x pode ser substituída por uma instalação do TomEE 1.0 sem afetar aplicações e scripts administrativos.

Assim sendo, o administrador de sistemas já sabe como instalar, iniciar e parar um servidor TomEE, e também como configurar coisas como domínios de segurança (Realms) e Datasources.

Já o desenvolvedor pode usar o suporte ao Tomcat presente nos IDEs Eclipse e NetBeans, não necessitando de um conector específico para o TomEE. É claro, o desenvolvedor deverá adicionar ao seu projeto no IDE as referências a APIs do Java EE não suportadas pelo Tomcat, por exemplo JSF, EJB e JPA. Mas não será necessário adicionar nenhum JAR ao projeto em si, muito menos ao pacote WAR gerado para deployment, pois eles já são parte do TomEE.
Edições do TomEE

o TomEE é na verdade a evolução do sub-projeto OpenEJB + Tomcat Integration da comunidade OpenEJB e substitui este projeto daqui em diante. Ele é fornecido em duas edições: o TomEE "simples" e o TomEE+ ("plus").

A edição "simples" é certificada no Java EE 6 Web Profile, mas ao contrário de outros servidores open source certificados neste padrão, não se limita a oferecer o EJB Lite. São suportados também EJBs com interfaces Remotas e pacotes EAR. E a clusterização não se limita a sessões HTTP, mas inclui também o estado de SFSBs.

Já a edição "plus" acrescenta um servidor JMS, serviços web JAX-WS e JAX-RS, e conectores JCA. Para a maioria dos desenvolvedores, ela oferece um servidor Java EE Full Profile, embora não tenha sido certificado como tal. A certificação não seria possível porque o TomEE+ não suporta funcionalidades legadas, por exemplo EJB 1 e 2, JAX-RPC e IIOP.
Componentes do TomEE

O TomEE reúne vários projetos da Apache Foundation, alguns dos quais já são bastante populares por si só, e também toma emprestado alguns componentes do Geronimo, outro servidor de aplicações mantido pela Fundação. Vale notar aqui que, embora o Geronimo 3.0 tenha sido certificado no Full Profile do Java EE 6, ele ainda é considerado beta pela sua comunidade.

Eis os principais componentes do TomEE "simples":

    OpenWebBeans (CDI)
    OpenEJB (EJB)
    OpenJPA (JPA)
    MyFaces (JSF)
    Geronimo Transaction (JTA)
    Geronimo JavaMail (Javamail)
    Apache Bean Validation (Bean Validation)

É claro, os interessados em utilizar outro provedor de persistência para o JPA, como o Hibernate, podem fazê-lo seguindo as normas do padrão Java EE. Já o uso de implementações alternativas para outras APIs, por exemplo o JSF, é mais complicado e não é recomendado pela comunidade.

O TomEE+ acrescenta:

    Apache CXF (JAX-WS, JAX-RS)
    Active MQ (JMS)
    Geronimo Connector (JCA)

O desenvolvedor encontra no site do projeto OpenEJB uma tabela indicando quais APIs são suportadas em cada edição do TomEE. Já o administrador irá apreciar a relação de arquivos acrescentados pelo TomEE em comparação com uma instalação do Tomcat 7.0.
TomEE em nuvem

As características do TomEE, especialmente a compatibilidade com o Tomcat e baixos requerimentos de memória e processador, o tornam bastante atrativo para ambientes de nuvem/cloud.

Uma feature do TomEE concebida especialmente para a nuvem é o arquivo de configuração scan.xml, que permite controle fino sobre quais pacotes JAR serão analisados em busca de anotações e TLDs. Também é possível configurar listas globais de pacotes JAR que não devem ser escaneados. Sem estas configurações, a inicialização de aplicações pode demorar demais, e a infraestrutura de nuvem pode abortar a instância, acreditando que está com problemas.

O TomEE já está, desde o beta, certificado para instâncias EC2 do Amazon AWS. Na verdade a infraestrutura do AWS foi utilizada para rodar o TCK do Java EE 6 Web Profile, trazendo assim duas certificações de uma tacada só.

Ainda não há planos para o suporte ao TomEE no Amazon Elastic Beanstalk, mas ele é bastante aguardado pela comunidade. Alguns usuários reportam sucesso na criação de imagens customizadas, transformando em um TomEE o Tomcat fornecido pelo serviço de nuvem.
Download e instalação

O TomEE pode ser baixado do site do projeto OpenEJB. Ambos os formatos zip e tar.gz fornecem scripts e arquivos bat para Windows, Mac, e Linux e outros Unixes. Ao contrário do que acontece para o Tomcat, não são fornecidos executáveis prontos para a instalação do TomEE como serviço do Windows, mas esta instalação pode ser feita manualmente usando-se os arquivos bat inclusos.

Também é possível baixar apenas os componentes do OpenEJB (e demais projetos), pré-empacotados em um único arquivo WAR, para acrescentar a uma instalação padrão do Tomcat. Neste caso, também será necessário editar o arquivo de configuação server.xml do Tomcat para acionar componentes do OpenEJB.

Fonte: InfoQ

Apache Shiro: Framework de Segurança em Java

Apache Shiro é um framework de segurança em Java, que realiza o gerenciamento dos processos de autenticação, de autorização, de sistemas de criptografia e sessão. Com API Shiro, você pode proteger qualquer aplicação - a partir de aplicações móveis até mesmo as maiores aplicações utilizadas em ambientes empresariais.

Como características principais, Apache Shiro apresenta:

Processos de Autenticação - com esse recurso, existe um suporte à logins em uma ou mais fontes de dados "pluggable" como LDAP, conectores JDBC, ActiveDirectory, entre outros; processos de autorização, onde é possível realizar o controle de acesso baseado em papéis ou permissões refinadas, utilizando também fontes de dados "pluggable".

Em relação ao sistema de criptografia, há um aumento na segurança de dados com as APIs de criptografia ( maior disponibilidade), dando-lhes poder e simplicidade, além do que o Java oferece por padrão. No que diz respeito ao gerenciamento de sessão, elas são utilizadas de forma facilitada em qualquer ambiente, mesmo fora da web ou em recipientes EJB. Também estão incluídas sessões de cluster em aplicações em grande escala.

Além das características mencionadas, há maior integração Web, associando uma grande economia de tempo de desenvolvimento com abordagens inovadoras, que lidam facilmente com especificações Web relacionadas à segurança, em modo out-of-the-box (fora da caixa).

Mais informações Apache Shiro http://shiro.apache.org/

Fonte: Under-linux

Desenvolvedores Apache Tomcat Aconselham Atualizações Para Evitar Ataques DoS

Os desenvolvedores do Apache Tomcat, estão aconselhando os usuários dos ramos 7.0.x, 6.0.x e 5.5.x do servlet container Java e JSP para atualizar para as últimas versões lançadas, a 7.0.23, 6.0.35 e a 5.5.35. Este aviso foi porque recentes investigações, revelaram ineficiências na forma como um grande número de parâmetros e valores de parâmetros foram tratados pelo Tomcat.

A análise da recente colisão de hash denial-of-service (DoS), havia permitido que os desenvolvedores identificassem todas as "ineficiências alheias", que podem ser exploradas por um pedido especialmente criado, fazendo com que grandes quantidades de CPU sejam ser consumidas. Para resolver o problema, os desenvolvedores modificaram o código para processar eficientemente um grande número de parâmetros e valores.

O projeto foi discretamente liberando as correções ao código do Tomcat; o ramo 7.0.23 apareceu no final de novembro de 2011, e o 6.0.35 chegou no início de dezembro. Agora que eles lançaram uma atualização para a última das versões suportadas atualmente, a 5.5.35, os desenvolvedores têm publicado seus "advisory". Usuários que podem baixar a versão atualizada a partir do site do Tom Cat.

Fonte: Under-Linux

Apache Struts Lança Atualização para Corrigir Falha de Segurança

Os desenvolvedores do Apache Struts, lançaram a versão 2.3.1.1 do seu framework de código aberto para aplicações baseadas em Java. A atualização fecha falhas críticas no Struts 2, fixando quatro vulnerabilidades de segurança antigas e bem conhecidas, que poderiam ser exploradas por um atacante para contornar as restrições, utilizando invocação de método dinâmico (CMS) para injetar e executar códigos Java maliciosos.

As versões 2.1.0 a 2.3.1 do Struts são afetados; upgrade para 2.3.1.1 corrige os problemas. Alternativamente, o alerta de segurança fornece instruções para alterar um arquivo de configuração que mitiga esse problema. Mais informações sobre a atualização podem ser encontradas nas notas de versão e assessoria de segurança do projeto. Struts 2.3.1.1 está disponível para download a partir do site do projeto.

Fonte: Under-Linux

Oracle Confirmao primeiro update para o Java 7

Quando o Java 7 foi lançado, ele veio com uma falha: usado com Apache Lucene e Apache Solr, o Java 7 causava cálculos incorretos e travava a Java Virtual Machine. Lucene e Solr ficavam praticamente paralisados.

Agora, a Oracle confirmou oficialmente que algumas das falhas foram corrigidas no Java 7 Update 1.

O problema foi descoberto alguns dias antes do lançamento do JDK 7, mas não houve tempo para corrigi-lo.

Embora a atualização tenha ficado pronta há alguns dias, as notas de lançamento não continham informações sobre o status dos bugs. Agora as IDs das falhas foram liberadas: 7068051, 7044738 e 7077439; e apesar de o bug 7070134 não estar identificado, ele também foi corrigido.

A Oracle também atualizou as notas de lançamento, confirmando que quatro problemas relacionados a JIT e a loop foram corrigidos.

De acordo com Uwe Schindler, comitter para Apache Lucene e Solr, agora é seguro usar Lucene e Solr com o 7 Update 1. Entretanto, ele aponta que não é recomendável utilizar o XX:AggressiveOpts em qualquer JVM em uso de produção.

Fonte: Imasters

Apache Cassandra

A Fundação Apache anunciou o lançamento da versão 1.0 do Cassandra.
O Projeto Apache Cassandra desenvolve um banco de dados altamente escalável de segunda geração distribuída, que reúne design totalmente distribuído Dynamo e ColumnFamily baseado Bigtable do modelo de dados.
Cassandra está em uso no Digg, Facebook, Twitter, Reddit, Rackspace, Cloudkick, Cisco, SimpleGeo, Ooyala, OpenX, e mais empresas que têm grandes conjuntos de dados ativos. O maior cluster de produção tem mais de 100 TB de dados em mais de 150 máquinas.
Cassandra é adequado para aplicações que não podem dar ao luxo de perder dados, mesmo quando um centro de dados inteiro vai para baixo.
Cada nó do cluster é idêntico. Não há pontos de estrangulamento da rede. Não há pontos únicos de falha.
Veja abaixo a apresentação do Cassandra.

Cassandra Explained

View more presentations from Eric Evans

Fonte: Guj, Br-Linux, Apache

Índices Solr - Atualiza ou Deleta?

De tempos em tempos, no trabalho com Solr há um problema comum - quando você atualizar a estrutura do índice Solr. Há várias razões para estas mudanças - os novos requisitos funcionais, otimização, ou qualquer outra coisa - não é importante. O importante é as perguntas que surgem - devemos remover o índice, ou simplesmente mudar a estrutura e fazer uma indexação completa? Contrariamente às aparências, a resposta a esta pergunta depende de as mudanças que fizemos na estrutura do índice.

Pessoalmente, eu sou um defensor de soluções que têm a menor chance de causar problemas - Eu só gosto de dormir à noite. Acho que a remoção do índice depois de atualizar sua estrutura e, em seguida, fazendo a correção monetária integral dos dados é uma dessas soluções, pelo menos na minha opinião. Estou ciente, no entanto, que este tipo de solução nem sempre é aceitável. Então, quando não somos obrigados a remover o índice, e quando é que vai nos expor para potenciais problemas com o Solr quando não fazê-lo?

A resposta à pergunta depende o que mudou na estrutura do índice. Tais mudanças podem ser divididas em três áreas que abrangem a maioria das mudanças que fazemos na estrutura do índice:

• Adição / remoção de novo campo

• Modificação semelhança

• Campo de modificação

Adição / remoção de novo campo

No caso do primeiro tipo de modificação da matéria é muito simples - se adicionar ou remover um novo campo no schema.xml não há necessidade de remover o índice inteiro antes de reindexação. Solr lida com a adição de um novo campo para o índice atual. Claro, você deve estar ciente de que os documentos que não será após esta operação não será re-indexados ou atualizada automaticamente.

Modificação semelhança

No segundo caso - a mudança da classe que é responsável por Similaridade também não nos força a excluir o índice depois da mudança. Mas, ao contrário do exemplo anterior, se quisermos que Solr calcule corretamente a pontuação e, portanto, para classificar na ordem correta, seremos forçados a reindexar todos os documentos anteriormente presentes no índice.

Campo de modificação

Vamos parar um minuto sobre o terceiro caso. Vamos supor que nós modificamos um pouco o campo no índice por um motivo prosaico - não estamos mais interessados na normalização do seu comprimento. Montamos omitNorms = "true" (presumo que a configuração anterior foi omitNorms = "false"). Se reindexar todos os documentos, os índices Lucene, nos segmentos combinados, ainda terá informações sobre a normalização do comprimento do campo. Algo deu errado. Este é precisamente o caso em que é necessário para excluir o índice após a mudança em sua estrutura, e antes da correção monetária integral. À primeira vista, parece que esta é uma mudança muito pequena, mas pensando mais longe, temos alguns efeitos colaterais da mudança. Vale lembrar que algumas das propriedades do campo são substituídos por outros, como no caso de normalização do comprimento - se um segmento terá normalização do comprimento, e o segundo não,é quando você combina os segmentos, você vai ter a normalização do comprimento naquele que foi criado.

Texto de Rafał Kuć e traduzido por @miguelcpjava
Texto Original: JavaLobby