Abstract: Comparison between primitive and object usage. Despite the java evolution, primitive usage has better performance

Este artigo compara a utilização de tipos primitivos e objetos.

public class App {

public static void main(String[] args) {

withLong();

withPrimitive();

}

private static void withLong(){

long start = System.currentTimeMillis();

Long sum = 0L;

for (long i = 0; i <= Integer.MAX_VALUE; i++) {

sum += i;

}

System.out.println(Double.valueOf(System.currentTimeMillis() - start) / 1000);

}

private static void withPrimitive(){

long start = System.currentTimeMillis();

long sum = 0;

for (long i = 0; i <= Integer.MAX_VALUE; i++) {

sum += i;

}

System.out.println(Double.valueOf(System.currentTimeMillis() - start) / 1000);

}

}

Ao executar o programa, constatamos que o uso do primitivo é, na média, 5 vezes mais rápido.

Desta maneira, a recomendação é: se você estiver manipulando uma grande quantidade de registros, como por exemplo, iterando uma lista de valores, de preferência ao primitivo. Se, trata-se de algo pontual, como tratar a idade em um formulário online, utilize o objeto.

Diagramas

Abstract: I was looking for tools that could help me to draw class and sequence diagrams. Into this post, I will describe my first impressions (here in Brazil we say that first impression remains) about what I found, hoping that it could help others.

Eu estava buscando por ferramentas que pudessem me ajudar a criar diagramas de classe e sequencia a partir de códigos existentes. A principio eu estava procurando ferramentas integradas ao Eclipse, mas isso não era um requisito mandatório. O principal era a capacidade de montar os diagramas automaticamente a partir do código.

Por enquanto, instalei 3 (e uma 4 tentativa frustrada). Foram: UMLet, ModelGoon, ObjectAID e JaMoPP.

Começando pela tentativa frustrada: JaMoPP. Apesar de não fazer nenhuma menção a diagramas de sequencia, resolvi testar pois a capacidade de gerar diagramas de classes a partir do código me pareceu promissora. Mas a documentação é muito ruim e até agora não entendi se é um framework ou se é uma ferramenta. Cheguei a instalar os pacotes, mas não consegui nem chegar perto de conseguir gerar um diagrama...

UMLet: só consegui fazer funcionar por fora, como uma aplicação standalone. Não achei intuitivo e demorei para conseguir fazer alguma coisa. Mas parece promissor e pretendo investir algum tempo em descobrir como funciona.

ModelGoon: fácil de usar. Os diagramas de classes são simples (se comparados aos que o ObjectAID cria) mas são eficientes. Ainda não consegui gerar o diagrama de sequencia, mas gostei muito do diagrama de dependências, que a principio nem fazia parte das minhas necessidades iniciais.

ObjectAID: também muito fácil de usar. O diagrama de classes é muito bom: colorido, flexível (você consegue ligar/desligar atributos apresentados). Mas para gerar o diagrama de sequencia, precisa comprar uma licença. Até fiquei tentado a comprar, dado a qualidade do diagrama de classes.

Por enquanto é isso. Fiquei meio indeciso se publicava ou não um post simples, só com primeiras impressões, pois me pareceu que agregava pouco. Mas, achei que valia a pena, pois no mínimo pode ajudar como ponto de partida e economizar algum tempo das pessoas na medida em que não precisarão ficar garimpando o marketplace...

Abstract: How to write a unit test that is able to instantiate a class using a constructor declared as private. By doing it, cobertura will include the test into its coverage report, helping you to achieve code coverage requirements.

É ponto pacífico que todo código deveria possuir testes unitários. Já para o que precisa ser testado e qual e extensão dos testes, não se tem uma regra clara e sempre gera discussões. Eu em geral busco 100% de cobertura.

Segundo algumas regras de estilo, "esconder" o construtor é uma boa prática e essa prática faz parte do manual de codificação para a empresa em que trabalho. O problema é que o cobertura (sistema que mede o percentual de testes que cobrem um código) não entende isso, e ao analisar o código fonte, acusa que faltam testes para o construtor privado. Com isso, o percentual de cobertura diminui.

Isso não é um problema, na medida em que se você construiu os testes para os métodos estáticos e eles estão funcionando, o construtor também irá funcionar. Mas, eu tenho TOC e depois de dar duro construindo testes, gosto de ver o relatório apontando 100%. Satisfação pessoal. Simples assim.

Então resolvi pesquisar se existiria uma maneira de fazer o cobertura entender que o construtor foi testado e encontrei um jeito legal de se fazer isso. Basta criar um teste unitário conforme exemplificado abaixo. Por reflexão ele irá instanciar a classe usando o método privado, e com isso, satisfazer o cobertura.

@Test

public void testPrivateConstructor() throws Exception {

   Constructor[] constructors = MyUtilityClass.class.getDeclaredConstructors();

// Only the private constructor
assertTrue(constructors.lenght == 1);

// And it should be private

assertFalse(constructors[0].isAccessible());



   constructors[0].setAccessible(true);

   constructors[0].newInstance((Object[])null);

}







BTW:

jumble = to move in a confused or disordered manner; to mix into a confused or disordered mass; an untidy collection or pile of things.

Validação de emails

Abstract: Java code that helps into email validation by checking if the domain has a DNS MX record. Into github, I provide a full working app other than the simple code of this post.

Na empresa para qual trabalho estávamos precisando de um validador de emails mais "potente" do que o javascript que verificava o formulário que coletava os emails dos nossos clientes. Ele basicamente validava se o email era bem formado.

Mas como saber se, apesar de bem formado, o email existe?

Antigamente era possível fazer um telnet na porta 25 e descobrir inclusive se o usuário existia. Mas com os spammers, isso acabou sendo bloqueado. Ainda dá para fazer, usando outra abordagem, mas isso é assunto para outro post.

Uma validação simples que pode ser feita é verificar se o domínio do email possui um servidor MX. MX vem de Mail eXchanger e é um registro que fica cadastrado em um DNS. É assim que a "internet" sabe para onde um email tem que ir.

Pesquisando, verifiquei que o java possui um contexto JNDI que nos ajuda com este tipo de tarefa e fica muito fácil fazer a verificação, conforme exemplo abaixo:

public void checkMX(String email) {

   Properties env = new Properties();

   env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.dns.DnsContextFactory");

   String hostname = email.substring(email.indexOf("@") + 1, email.length()).toLowerCase().trim();

   try {

      InitialDirContext idc = new InitialDirContext(env);

      Attributes attributes = idc.getAttributes(hostname, new String[] { "MX" });

      Attribute attribute = attributes.get("MX");

      System.out.println(attribute);

   } catch (NamingException e) {

      e.printStackTrace();

   }

}

Se você chamar o método e passar um email do gmail, ele vai imprimir na console "MX: 5 gmail-smtp-in.l.google.com., 40 alt4.gmail-smtp-in.l.google.com., 10 alt1.gmail-smtp-in.l.google.com., 20 alt2.gmail-smtp-in.l.google.com., 30 alt3.gmail-smtp-in.l.google.com.".

Os números na frente dos servidores indica a prioridade. Quanto menor, mais importante. No exemplo acima, primeiro o email tentará ser entregue ao servidor com prioridade 5, depois 10 e assim por diante.

Na minha conta do github eu coloquei uma aplicação um pouco mais completa, que lê um arquivo texto com uma lista de emails e gera um log de processamento com o resultado das validações.

Espero que seja útil.