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

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:

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

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.

[quote=asaudate]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.
[/quote]

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! :lol:

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?

[quote=alias][quote=asaudate]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.
[/quote]

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! :lol:

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?[/quote]

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!

[quote=asaudate]
BigDecimal ou BigInteger ou long resolvem o problema.
[]'s[/quote]

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. )

[quote=entanglement][quote=asaudate]
BigDecimal ou BigInteger ou long resolvem o problema.
[]'s[/quote]

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. )[/quote]

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

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.

[quote=entanglement]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.
[/quote]

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

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 :slight_smile:

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!

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 :)[/quote]

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. :smiley:

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.

Além de virar uma salada, tem também o problema da precisão do resultado. Cálculos devem ser, digamos, precisos. Ainda mais quando se trata de cálculos monetários, lidando com dinheiro dos outros. E todos nós sabemos que trabalhar unicamente com tipos primitivos para realizar operações matemáticas pode gerar muitos resultados errôneos.

O Java já possui classes para muitos tipos básicos, como Integer e String. Uma classe Money (de forma semelhante ao pattern citado no livro do Fowler) cairia muito bem pra plataforma.

(OBS:apenas citei o pattern por não conhecer implementação melhor para representar dinheiro)

E a JSR 310 (Date and Time API ) em galera ? Morreu mesmo ? Que demora para uma padronização que deveria ser rapida , não ?

Na minha visão demorou pra sair isso.

Entendo que essa JSR é motivada pela forte tendência do dinheiro em papel ser substituido de fato pelo dinheiro eletrônico.

Legal, acho que meus bisnetos vão gostar

[quote=Adriano Almeida]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:

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 [/quote]

Pela velocidade que as coisas acontecem no Java, talvez em 2016 teremos esta API lançada …
Enquanto isso, tenho uma implementação do Money Pattern do Martin Fowler no Github