31 de janeiro de 2014

Projeto JRimum no GitHub

Depois do Octal em Java agora voltamos para anunciar o JRimum no Octocat, ou melhor, no GitHub:


A migração de código já foi realizada há alguns meses e a conta do JRimum, nossa, nem se fala,  acreditem, ela foi criada em 2011; e sendo mais preciso ainda, foi no dia 10 de Junho. Coincidência ou não, isso foi logo após o último release "oficial" do projeto em 2011/04/15.

O que estou querendo dizer é que pretendíamos fazer várias melhorias há muito tempo, mas que por vários motivos não foi possível.

Desde lá, muita coisa passou e mudou,  inclusive eu :-), falo mais dessas mudanças "aqui no meu blog". Mas eu e meus colegas Rômulo e Misael, os 3 principais desenvolvedores do projeto, ficamos muito contentes em saber que o projeto agradou tantos os desenvolvedores e as empresas e concordamos que o projeto não poderia parar sob hipótese alguma, então esse tempo todo mantivemos pelo menos o suporte respondendo o pessoal no grupo.

Agora estamos entrando realmente em uma nova fase, bom, pelo menos posso falar que, para mim é uma outra fase :-) e para começar com o pé direto, gostaríamos de anunciar os planos do projeto e convidá-los para participar do desenvolvimento das próximas versões.

Teremos mais detalhes sobre o desenvolvimento e releases na próxima semana.

Colabore conosco no JRimum-Community

4 de abril de 2013

Octal em Java

Olá Pessoal!

Estamos de volta com um assunto que, para nossa surpresa, tem uma certa frequência no nosso fórum:

O uso de números octais em Java.

Na verdade o assunto não surge como subject das threads, mas sim, como equívocos causados durante o uso da API do projeto.

E por isso, devido a relativa relevância deste "problema", resolvemos criar este post :-)

Vamos lá, o que vocês acham: seria um problema de design da API? Ou simplesmente um error-prone da linguagem Java no que diz respeito a manipulação dos números?

Vamos ao problema,... mas antes consideremos a relevância do problema para nós; bom, nesses 5 anos de projeto JRimum, já chegamos a ter 6 threads relacionadas ao assunto:


Isso nos daria uma média de 1 thread por ano (considerando que uma delas não foi um erro e sim uma sugestão).

Para nós isso tem relevância, pois nos força a explicar, na maioria das vezes, o porquê um usuário da API está enfrentando aquela situação, aparentemente sem lógica para ele. Dessa forma, preferimos criar um post para fazer referência ao problema quando ele ocorrer novamente ano que vem, correto? Isso é, vamos fazer uso do reuso :-)

O Problema:


Normalmente o problema/situação surge na utilização de objetos como:
  • Agencia  
  • Carteira 
  • NumeroDaConta;
Onde esses objetos são instanciados com valores do tipo java.lang.Integer, como:

new Agencia(01234,"7");

O problema está no primeiro zero, mas por quê? Lá vai, simples e direto: porque em Java um número do tipo Inteiro com zero na frente é considerado como um Octal. Veja em:

http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html

Se você não sabia e ainda está desconfiado, veja o que acontece se executar esse simples exemplo:

Integer inteiro = 0717;
System.out.println(inteiro);

Pois é, a saída será 463 que é o valor de um número do tipo Inteiro correspondente ao Octal "0717" e não o número do tipo Inteiro 717. Mas você que é novato no Java, ou por algum motivo desconhece o uso do Octal, ainda pode pensar: "mas isso é coisa do tal do Autoboxing não?". Ok, então vamos ver agora um outro exemplo:

Integer numero = Integer.valueOf(010);

Será que a saída vai ser 10 (Dez)? Ainda acredita nisso? Sério? É, se você executou esse código, não foi isso que você viu. O que você acabou de ver foi que a variável numero corresponde na verdade a 8 (Oito), pois você atribuiu um 8 (Oito) escrito em Octal (porque começa com zero) a uma variável do tipo Inteiro. E quando você visualiza a saída, daí você vê exatamente o número 8 do tipo Inteiro e não o dez que você escreveu.

Portanto: Integer.valueOf(010) == 8

Para saber mais sobre os tipos numéricos do Java veja em:

http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

Calma, não se preocupe caso você tenha cometido erros com Octais. Este não é um equivoco raro entre programadores iniciantes em Java, mas esperamos que este erro não se repita em seus programas nunca mais :-)

E aqueles que acham que é um problema da API? Bom, podemos ver erros semelhantes em outras API de mesmo propósito também:

http://www.guj.com.br/java/262410-stella---boleto---codigo-do-cedente-03036

A Solução?


Caso você ainda não tenha percebido e ache que isso realmente é um problema, então sua solução é:

Remova o(s) zero(s) antes do número do tipo Inteiro.

Pronto, essa era a moral da história. Caso queira saber mais sobre o sistema de numeração Ocatal veja:

http://pt.wikipedia.org/wiki/Octal

Até a próxima!

28 de setembro de 2012

Trac/SVN em Manutenção


Olá Pessoal!

Quanto tempo?! :-)

Bom, o momento é de planejamento e transição para nós, por isso a "pausa" das atividades, além de outros problemas de força maior que houveram com nossos desenvolvedores.

Mas, o que quero informar é que, fomos avisados (hoje) que:

A partir de hoje (sexta-feira 28/09) até segunda-feira (01/10), o servidor que hospeda o trac/svn do projeto jrimum (www.jrimum.org) estará em manutenção e provavelmente estará fora do ar.

Entretanto, vale lembrar que outros recursos como:


Estarão ativos.

Agradecemos a compreensão de todos.

24 de novembro de 2011

Mudança no nome dos artefatos maven

Bem pessoal, vocês viram que acabamos de publicar o repositório maven, inicialmente para versões "snapshot". Não precisou de muito tempo para perceber que deveríamos melhorar a organização dos artefatos.

Por causa disso, fizemos uma pequena mudança:

O anunciado foi

<dependency>
   <groupId>org.jrimum</groupId>
   <artifactId>bopepo</artifactId>
   <version>0.2.3-SNAPSHOT</version>
</dependency>

E agora está

<dependency>
   <groupId>org.jrimum</groupId>
   <artifactId>jrimum-bopepo</artifactId>
   <version>0.2.3-SNAPSHOT</version>
</dependency>

Ou seja, agora tem o prefixo "jrimum". Além do Bopepo, todas as suas dependências que também fazem parte do Projeto JRimum foram atualizadas.

Assim fica mais organizado e mais fácil de você achar as libs do JRimum.

Por enquanto é só galera! Valeu!

21 de novembro de 2011

Repositório Maven

Olá amigos!

É com muito prazer que anunciamos nosso recém criado repositório maven:


Agora não podemos deixar de lembrar e agradecer ao nosso amigo, que também faz parte da equipe de desenvolvimento: Rômulo Santos, pelo empenho na instalação, configuração, etc.. do repositório. Valeu mesmo cara!  

Bom, voltando ao fruto do trabalho do nosso amigo,.. :-) Para quem utiliza o maven, já sabe, é simples! Basta adicionar o repositório do jrimum ao "pom.xml" do seu projeto:

<repository>
   <id>jrimum.org</id>
   <url>http://jrimum.org/maven/content/groups/public/</url>
   <snapshots>
      <enabled>true</enabled>
   </snapshots>
</repository>

Juntamente com a declaração da dependência em questão, atualmente muitos provavelmente utilizarão o Bopepo:

<!-- Dependências do projeto JRimum -->
<dependency>
   <groupId>org.jrimum</groupId>
   <artifactId>jrimum-bopepo</artifactId>
   <version>0.2.3-SNAPSHOT</version>
</dependency>

E pronto! Já foi! Calma, sabemos que muitos não gostam do maven ou não utilizam por diversos motivos (limitação em projetos, familiaridade, preferência, etc.). Portanto, independente do motivo, não é por conta disso que você ficará desatualizado em relação aos snapshots e releases do projeto JRimum. Aqui está a interface gráfica do Nexus:


Aqui você pode digitar, e procurar pelo componente que desejar. Para ver os arquivos disponíveis, por exemplo, do Bopepo, basta digitar bopepo e você verá os artefatos disponíveis como na figura abaixo:


Ou também, se quiser ir "direto ao ponto", você pode ir na view de navegação do repositório público:


É isso pessoal, hoje (na data deste post), alguns assuntos tratados na lista de discussão jrimum-community já foram resolvidos e as soluções estão disponíveis nos snapshots, alguns são:
Esperamos que agora as mudanças estejam disponíveis o mais rápido possível! Quem sabe o Papai Noel não nos deixe mais surpresas como essa nos próximos dias :-)