JSR 354: Money and Currency API - Nova especificação para trabalhar com valores monetários

JavaEvangelist Membro desde: 13/09/2006 15:29:34 Mensagens: 386 Offline

Desde o começo desse ano, começou um trabalho para desenvolver uma nova especificação no Java para auxiliar o trabalho com valores monetários, que é a JSR 354 - Money and Currency API. A especificação, que possui como líder o banco Credit Suisse, membro do JCP, também possui como um dos seus membros de Expert Group o Stephen Colebourne, que participou de outras especificações, como a Date and Time API (JSR 310), junto dos brasileiros Michael Nascimento e Fabio Kung.

Segundo a descrição da especifição:

Provides an API for representing, transporting, and performing comprehensive calculations with Money and Currency.

Vale lembrar que essa especificação está em estágio bastante inicial, mas não deixa de ser uma boa notícia para empresas que trabalham com sistemas financeiros e cálculos em moedas.

Para saber mais sobre a especificação, a página dela é http://jcp.org/en/jsr/detail?id=354

This message was edited 1 time. Last update was at 17/01/2012 13:39:25

Excelente notícia! Já perdí as contas de quantos lugares eu ví em que Double era usado para realizar cálculos com dinheiro... Resta esperar que as pessoas usem, de fato, a API nova.

Virtual Machine Man Membro desde: 11/06/2007 11:09:34 Mensagens: 596 Offline

asaudate wrote:Excelente notícia! Já perdí as contas de quantos lugares eu ví em que Double era usado para realizar cálculos com dinheiro... Resta esperar que as pessoas usem, de fato, a API nova.

Tem razão, certa vez trabalhei em uma consultoria prestando serviço em um banco, e os "arquitetos" do lugar criaram uma classe wrapper de Float para operações com moeda. Genial!

Amigos me perdoem a ignorancia, mas nao é um pouco bizarro ter uma especificação para tratar calculo de moedas? Talvez seja miopia minha mas voces conseguem enxergar muitas variacoes de implementação para fazer isso?

alias wrote:

asaudate wrote:Excelente notícia! Já perdí as contas de quantos lugares eu ví em que Double era usado para realizar cálculos com dinheiro... Resta esperar que as pessoas usem, de fato, a API nova.

Tem razão, certa vez trabalhei em uma consultoria prestando serviço em um banco, e os "arquitetos" do lugar criaram uma classe wrapper de Float para operações com moeda. Genial!

Amigos me perdoem a ignorancia, mas nao é um pouco bizarro ter uma especificação para tratar calculo de moedas? Talvez seja miopia minha mas voces conseguem enxergar muitas variacoes de implementação para fazer isso?

BigDecimal ou BigInteger ou long resolvem o problema. O caso é que converter qualquer um dos três em moeda requer algumas artimanhas. O próprio Martin Fowler catalogou um pattern chamado Money (está no livro Patterns of Enterprise Application Architecture).

[]'s

Excelente notícia. Tava mais do que na hora.

Acredito que essa JSR seja tão importante quanto a de datas. São conceitos que aplicamos em tudo quanto é sistema, e em cada um fazendo uma solução caseira.
Achei interessante também que o líder da especificação seja um banco. Instituições financeiras são mais do que interessadas numa API dessas, e nada melhor do que uma delas pra dizer o que deve ser feito.

Tomara que vingue!

GUJ Hacker Membro desde: 26/09/2009 09:18:56 Mensagens: 5750 Offline

asaudate wrote:
BigDecimal ou BigInteger ou long resolvem o problema.
[]'s

Mais ou menos - na verdade, seria mais eficiente se houvesse um tipo como o System.Decimal (a.k.a. "decimal") do C#, que é um "Ponto flutuante decimal" que é mais eficiente que o velho e bom BigDecimal. (A propósito, passando os parâmetros adequados para o construtor do java.math.BigDecimal, ele se comporta como um "Ponto Flutuante Decimal", mas isso deveria ser tratado por uma classe separada, para evidenciar o fato que ele nesse caso tem precisão limitada. )

entanglement wrote:

asaudate wrote:
BigDecimal ou BigInteger ou long resolvem o problema.
[]'s

Mais ou menos - na verdade, seria mais eficiente se houvesse um tipo como o System.Decimal (a.k.a. "decimal") do C#, que é um "Ponto flutuante decimal" que é mais eficiente que o velho e bom BigDecimal. (A propósito, passando os parâmetros adequados para o construtor do java.math.BigDecimal, ele se comporta como um "Ponto Flutuante Decimal", mas isso deveria ser tratado por uma classe separada, para evidenciar o fato que ele nesse caso tem precisão limitada. )

Não entendí muito bem essa parte, seria sacrificar a precisão em favor da eficiência?

GUJ Hacker Membro desde: 26/09/2009 09:18:56 Mensagens: 5750 Offline

A menos que você esteja lidando com dólares zimbabuanos (que foram abolidos no Zimbábue em 2009) - onde você poderia ter quantias que eram de centenas de trilhões, acho que você não precisa usar mais que 20 casas nos cálculos monetários.

entanglement wrote:A menos que você esteja lidando com dólares zimbabuanos (que foram abolidos no Zimbábue em 2009) - onde você poderia ter quantias que eram de centenas de trilhões, acho que você não precisa usar mais que 20 casas nos cálculos monetários.

E a representação de todo o dinheiro em circulação no mundo, convertido em yens ? =)

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

alias wrote:Amigos me perdoem a ignorancia, mas nao é um pouco bizarro ter uma especificação para tratar calculo de moedas? Talvez seja miopia minha mas voces conseguem enxergar muitas variacoes de implementação para fazer isso?

Há trocentas implementações disso, o problema é a maioria usar a implementação com float e double, sem saber dos riscos. Padronizar para uma solução, neste caso, daria mais visibilidade, e corretude para o mundo Java.

Edit: O Bitcoin, na implementação atual, tem até 8 casas decimais, podendo acumular até 21 milhões. Quantias grandes

Apesar de simples o problema decorrente de uma implementação feita com os tipos errados pode ser complicado de resolver... experiência própria. Espero que tendo um padrão para isso vai force o pessoal a implementar da maneira certa!

Bruno Laturner wrote:

alias wrote:Amigos me perdoem a ignorancia, mas nao é um pouco bizarro ter uma especificação para tratar calculo de moedas? Talvez seja miopia minha mas voces conseguem enxergar muitas variacoes de implementação para fazer isso?

Há trocentas implementações disso, o problema é a maioria usar a implementação com float e double, sem saber dos riscos. Padronizar para uma solução, neste caso, daria mais visibilidade, e corretude para o mundo Java.

Edit: O Bitcoin, na implementação atual, tem até 8 casas decimais, podendo acumular até 21 milhões. Quantias grandes

Você acha 21 milhões grande? O Faustão ganha mais que isso em menos de um ano...

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

asaudate wrote:Você acha 21 milhões grande? O Faustão ganha mais que isso em menos de um ano...

21 mi é peixe pequeno, 2 quatrilhões e 100 trilhões que é o bicho.

Ja não era sem tempo!Uma padronização facilitara(e muito) a nossa vida.

Sim, também vejo a padronização como um grande benefício. É lógico que dá para trabalhar da maneira atual, mas cada um faz do seu jeito, ou usa double, big, classe wrapper, vira uma salada.

Notícias, artigos e o maior fórum brasileiro sobre Java