joda-money-interest Mailing List for Joda - Money
Project moved to GitHub
Status: Alpha
Brought to you by:
scolebourne
You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(7) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Stephen C. <sco...@jo...> - 2013-01-31 23:00:45
|
Yes, v0.7 works in Java 5. thanks Stephen On 31 January 2013 21:47, Rebecca Relyea <Reb...@s5...> wrote: > Hello, > > I would like to use joda-money but I am stuck on Java 1.5 for the next 6 > months. I noticed that version 0.8 requires java version 1.6. Does version > 0.7 work on Java 1.5? > > Thanks! Rebecca > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > |
From: Rebecca R. <Reb...@s5...> - 2013-01-31 22:04:12
|
Hello, I would like to use joda-money but I am stuck on Java 1.5 for the next 6 months. I noticed that version 0.8 requires java version 1.6. Does version 0.7 work on Java 1.5? Thanks! Rebecca |
From: Stephen C. <sco...@jo...> - 2012-03-21 10:27:42
|
Wouldn't you also end up with units of money squared in the same way as 2km multiplied by 2km would give 4square-km. Stephen On 20 March 2012 20:23, Gerson Motoyama <ge...@gm...> wrote: > Ok, I get it... it's because the rounding should be necessary anyway because > multiplication changes the original scale. > > > On Tue, Mar 20, 2012 at 5:11 PM, Gerson Motoyama <ge...@gm...> wrote: >> >> Is there any reason not to include a method 'mutipliedBy(Money)' to Money >> class? >> >> Gerson > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > |
From: Gerson M. <ge...@gm...> - 2012-03-20 20:23:07
|
Ok, I get it... it's because the rounding should be necessary anyway because multiplication changes the original scale. On Tue, Mar 20, 2012 at 5:11 PM, Gerson Motoyama <ge...@gm...> wrote: > Is there any reason not to include a method 'mutipliedBy(Money)' to Money > class? > > Gerson > |
From: Gerson M. <ge...@gm...> - 2012-03-20 20:11:26
|
Is there any reason not to include a method 'mutipliedBy(Money)' to Money class? Gerson |
From: Stephen C. <sco...@jo...> - 2011-08-01 00:59:34
|
I've released Joda-Money 0.6 Download https://sourceforge.net/projects/joda-money/files/joda-money/0.6/ This puts a marker in the ground on the project. If anyone is using it, please let me know. Does it need more work, changes, or should it become 1.0? Stephen |
From: Stephen C. <sco...@jo...> - 2011-05-13 16:24:00
|
All, FYI, the primary source code repository for this project has changed to be at github: https://github.com/JodaOrg/joda-money The project home page remains at Sourceforge, which also has a mirror git repo. Stephen |
From: Stephen C. <sco...@jo...> - 2010-12-08 10:08:29
|
I've got toolchains in profiles working now in the joda-convert and joda-time projects. So, we should do the same here. Stephen On 8 December 2010 04:52, Tauren Mills <ta...@gr...> wrote: > I completely understand, I've spent way more time on Maven than I should > have. > If you do go with profiles at some point, here's an example of doing > profiles from another mailing list I follow: > http://www.mail-archive.com/us...@wi.../msg44986.html > Tauren > > On Fri, Dec 3, 2010 at 7:37 AM, Stephen Colebourne <sco...@jo...> > wrote: >> >> Agreed, profiles might be the answer. But I seem to spend more time on >> maven issues than coding, which isn't good! >> Stephen >> >> On 3 December 2010 14:50, Tauren Mills <ta...@gr...> wrote: >> > Stephen, >> > Fair enough -- you need to do what works best for you as the developer. >> > My >> > goal was simply to let you know that the build might not be working for >> > others if you were assuming it was. >> > I'm certainly no maven expert. I do wonder if it would be possible to >> > use >> > Maven Profiles to solve the problem. This way, you could have a >> > consistent >> > build by specifying a profile via the command line, an environment >> > variable, >> > or some other means. But for the average Joe who checks out the code, a >> > default profile would be used that is more likely to work anywhere. >> > >> > http://maven.apache.org/guides/introduction/introduction-to-profiles.html >> > I've never used profiles before, and perhaps there are better solutions. >> > Not >> > terribly important for a low profile project like this one, but it could >> > be >> > useful with joda-time. >> > Thanks, >> > Tauren >> > >> > >> > >> > On Fri, Dec 3, 2010 at 5:36 AM, Stephen Colebourne >> > <sco...@jo...> >> > wrote: >> >> >> >> I find maven to be a right royal pain. Whatever I setup for me isn't >> >> right for someone else. The toolchain code is to ensure that the built >> >> version uses Java 5, which is necessary to get a consistent release >> >> (as maven is useless at prducing reproducible builds). As far as I >> >> know, this is the correct way to ensure that the build is Java 5, but >> >> maybe there is a less intrusive way. >> >> >> >> Stephen >> >> >> >> >> >> On 3 December 2010 07:22, Tauren Mills <ta...@gr...> wrote: >> >> > I ran into some problems building Joda Money because it requires that >> >> > I >> >> > have >> >> > a ~/.m2/toolchains.xml file. I didn't have this file and had to >> >> > research >> >> > what it was and then create it. I have used Maven a lot, but never >> >> > have >> >> > happened upon this feature yet. >> >> > When building, I got this error: >> >> > >> >> > 12/2/10 10:54:06 PM PST: [ERROR] Cannot find matching toolchain >> >> > definitions >> >> > for the following toolchain types: >> >> > jdk [ vendor='sun' version='1.5' ] >> >> > 12/2/10 10:54:06 PM PST: Build errors for joda-money; >> >> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to >> >> > execute >> >> > goal org.apache.maven.plugins:maven-toolchains-plugin:1.0:toolchain >> >> > (default) on project joda-money: Cannot find matching toolchain >> >> > definitions >> >> > for the following toolchain types: >> >> > jdk [ vendor='sun' version='1.5' ] >> >> > Please make sure you define the required toolchains in your >> >> > ~/.m2/toolchains.xml file. >> >> > I didn't want to install JDK 1.5, so I faked it by adding a >> >> > toolchains.xml >> >> > file that looks like this: >> >> > <?xml version="1.0" encoding="UTF8"?> >> >> > <toolchains> >> >> > <toolchain> >> >> > <type>jdk</type> >> >> > <provides> >> >> > <version>1.5</version> >> >> > <vendor>sun</vendor> >> >> > <id>default</id> >> >> > </provides> >> >> > <configuration> >> >> > <jdkHome>/usr/lib/jvm/java-6-sun</jdkHome> >> >> > </configuration> >> >> > </toolchain> >> >> > </toolchains> >> >> > Is there a reason for this requirement? What if I want to build it >> >> > with >> >> > JDK >> >> > 1.6 instead of 1.5? In my mind, anything that makes it more difficult >> >> > for >> >> > people to build, the less likely they are to do so. I would think >> >> > that >> >> > checking out the source from SVN and running "mvn install" should >> >> > just >> >> > work. >> >> > Thanks, >> >> > Tauren >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ >> >> > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> >> > Tap into the largest installed PC base & get more eyes on your game >> >> > by >> >> > optimizing for Intel(R) Graphics Technology. Get started today with >> >> > the >> >> > Intel(R) Software Partner Program. Five $500 cash prizes are up for >> >> > grabs. >> >> > http://p.sf.net/sfu/intelisp-dev2dev >> >> > _______________________________________________ >> >> > Joda-money-interest mailing list >> >> > Jod...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/joda-money-interest >> >> > >> >> > >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> >> Tap into the largest installed PC base & get more eyes on your game by >> >> optimizing for Intel(R) Graphics Technology. Get started today with the >> >> Intel(R) Software Partner Program. Five $500 cash prizes are up for >> >> grabs. >> >> http://p.sf.net/sfu/intelisp-dev2dev >> >> _______________________________________________ >> >> Joda-money-interest mailing list >> >> Jod...@li... >> >> https://lists.sourceforge.net/lists/listinfo/joda-money-interest >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> > Tap into the largest installed PC base & get more eyes on your game by >> > optimizing for Intel(R) Graphics Technology. Get started today with the >> > Intel(R) Software Partner Program. Five $500 cash prizes are up for >> > grabs. >> > http://p.sf.net/sfu/intelisp-dev2dev >> > _______________________________________________ >> > Joda-money-interest mailing list >> > Jod...@li... >> > https://lists.sourceforge.net/lists/listinfo/joda-money-interest >> > >> > >> >> >> ------------------------------------------------------------------------------ >> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> Tap into the largest installed PC base & get more eyes on your game by >> optimizing for Intel(R) Graphics Technology. Get started today with the >> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >> http://p.sf.net/sfu/intelisp-dev2dev >> _______________________________________________ >> Joda-money-interest mailing list >> Jod...@li... >> https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > |
From: Tauren M. <ta...@gr...> - 2010-12-08 04:53:05
|
I completely understand, I've spent way more time on Maven than I should have. If you do go with profiles at some point, here's an example of doing profiles from another mailing list I follow: http://www.mail-archive.com/us...@wi.../msg44986.html Tauren On Fri, Dec 3, 2010 at 7:37 AM, Stephen Colebourne <sco...@jo...>wrote: > Agreed, profiles might be the answer. But I seem to spend more time on > maven issues than coding, which isn't good! > Stephen > > On 3 December 2010 14:50, Tauren Mills <ta...@gr...> wrote: > > Stephen, > > Fair enough -- you need to do what works best for you as the developer. > My > > goal was simply to let you know that the build might not be working for > > others if you were assuming it was. > > I'm certainly no maven expert. I do wonder if it would be possible to use > > Maven Profiles to solve the problem. This way, you could have a > consistent > > build by specifying a profile via the command line, an environment > variable, > > or some other means. But for the average Joe who checks out the code, a > > default profile would be used that is more likely to work anywhere. > > > http://maven.apache.org/guides/introduction/introduction-to-profiles.html > > I've never used profiles before, and perhaps there are better solutions. > Not > > terribly important for a low profile project like this one, but it could > be > > useful with joda-time. > > Thanks, > > Tauren > > > > > > > > On Fri, Dec 3, 2010 at 5:36 AM, Stephen Colebourne <sco...@jo... > > > > wrote: > >> > >> I find maven to be a right royal pain. Whatever I setup for me isn't > >> right for someone else. The toolchain code is to ensure that the built > >> version uses Java 5, which is necessary to get a consistent release > >> (as maven is useless at prducing reproducible builds). As far as I > >> know, this is the correct way to ensure that the build is Java 5, but > >> maybe there is a less intrusive way. > >> > >> Stephen > >> > >> > >> On 3 December 2010 07:22, Tauren Mills <ta...@gr...> wrote: > >> > I ran into some problems building Joda Money because it requires that > I > >> > have > >> > a ~/.m2/toolchains.xml file. I didn't have this file and had to > research > >> > what it was and then create it. I have used Maven a lot, but never > have > >> > happened upon this feature yet. > >> > When building, I got this error: > >> > > >> > 12/2/10 10:54:06 PM PST: [ERROR] Cannot find matching toolchain > >> > definitions > >> > for the following toolchain types: > >> > jdk [ vendor='sun' version='1.5' ] > >> > 12/2/10 10:54:06 PM PST: Build errors for joda-money; > >> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > >> > execute > >> > goal org.apache.maven.plugins:maven-toolchains-plugin:1.0:toolchain > >> > (default) on project joda-money: Cannot find matching toolchain > >> > definitions > >> > for the following toolchain types: > >> > jdk [ vendor='sun' version='1.5' ] > >> > Please make sure you define the required toolchains in your > >> > ~/.m2/toolchains.xml file. > >> > I didn't want to install JDK 1.5, so I faked it by adding a > >> > toolchains.xml > >> > file that looks like this: > >> > <?xml version="1.0" encoding="UTF8"?> > >> > <toolchains> > >> > <toolchain> > >> > <type>jdk</type> > >> > <provides> > >> > <version>1.5</version> > >> > <vendor>sun</vendor> > >> > <id>default</id> > >> > </provides> > >> > <configuration> > >> > <jdkHome>/usr/lib/jvm/java-6-sun</jdkHome> > >> > </configuration> > >> > </toolchain> > >> > </toolchains> > >> > Is there a reason for this requirement? What if I want to build it > with > >> > JDK > >> > 1.6 instead of 1.5? In my mind, anything that makes it more difficult > >> > for > >> > people to build, the less likely they are to do so. I would think that > >> > checking out the source from SVN and running "mvn install" should just > >> > work. > >> > Thanks, > >> > Tauren > >> > > >> > > >> > > ------------------------------------------------------------------------------ > >> > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > >> > Tap into the largest installed PC base & get more eyes on your game by > >> > optimizing for Intel(R) Graphics Technology. Get started today with > the > >> > Intel(R) Software Partner Program. Five $500 cash prizes are up for > >> > grabs. > >> > http://p.sf.net/sfu/intelisp-dev2dev > >> > _______________________________________________ > >> > Joda-money-interest mailing list > >> > Jod...@li... > >> > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > >> > > >> > > >> > >> > >> > ------------------------------------------------------------------------------ > >> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > >> Tap into the largest installed PC base & get more eyes on your game by > >> optimizing for Intel(R) Graphics Technology. Get started today with the > >> Intel(R) Software Partner Program. Five $500 cash prizes are up for > grabs. > >> http://p.sf.net/sfu/intelisp-dev2dev > >> _______________________________________________ > >> Joda-money-interest mailing list > >> Jod...@li... > >> https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > > > > > > ------------------------------------------------------------------------------ > > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > > Tap into the largest installed PC base & get more eyes on your game by > > optimizing for Intel(R) Graphics Technology. Get started today with the > > Intel(R) Software Partner Program. Five $500 cash prizes are up for > grabs. > > http://p.sf.net/sfu/intelisp-dev2dev > > _______________________________________________ > > Joda-money-interest mailing list > > Jod...@li... > > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > > > > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > |
From: Stephen C. <sco...@jo...> - 2010-12-03 15:37:51
|
Agreed, profiles might be the answer. But I seem to spend more time on maven issues than coding, which isn't good! Stephen On 3 December 2010 14:50, Tauren Mills <ta...@gr...> wrote: > Stephen, > Fair enough -- you need to do what works best for you as the developer. My > goal was simply to let you know that the build might not be working for > others if you were assuming it was. > I'm certainly no maven expert. I do wonder if it would be possible to use > Maven Profiles to solve the problem. This way, you could have a consistent > build by specifying a profile via the command line, an environment variable, > or some other means. But for the average Joe who checks out the code, a > default profile would be used that is more likely to work anywhere. > http://maven.apache.org/guides/introduction/introduction-to-profiles.html > I've never used profiles before, and perhaps there are better solutions. Not > terribly important for a low profile project like this one, but it could be > useful with joda-time. > Thanks, > Tauren > > > > On Fri, Dec 3, 2010 at 5:36 AM, Stephen Colebourne <sco...@jo...> > wrote: >> >> I find maven to be a right royal pain. Whatever I setup for me isn't >> right for someone else. The toolchain code is to ensure that the built >> version uses Java 5, which is necessary to get a consistent release >> (as maven is useless at prducing reproducible builds). As far as I >> know, this is the correct way to ensure that the build is Java 5, but >> maybe there is a less intrusive way. >> >> Stephen >> >> >> On 3 December 2010 07:22, Tauren Mills <ta...@gr...> wrote: >> > I ran into some problems building Joda Money because it requires that I >> > have >> > a ~/.m2/toolchains.xml file. I didn't have this file and had to research >> > what it was and then create it. I have used Maven a lot, but never have >> > happened upon this feature yet. >> > When building, I got this error: >> > >> > 12/2/10 10:54:06 PM PST: [ERROR] Cannot find matching toolchain >> > definitions >> > for the following toolchain types: >> > jdk [ vendor='sun' version='1.5' ] >> > 12/2/10 10:54:06 PM PST: Build errors for joda-money; >> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to >> > execute >> > goal org.apache.maven.plugins:maven-toolchains-plugin:1.0:toolchain >> > (default) on project joda-money: Cannot find matching toolchain >> > definitions >> > for the following toolchain types: >> > jdk [ vendor='sun' version='1.5' ] >> > Please make sure you define the required toolchains in your >> > ~/.m2/toolchains.xml file. >> > I didn't want to install JDK 1.5, so I faked it by adding a >> > toolchains.xml >> > file that looks like this: >> > <?xml version="1.0" encoding="UTF8"?> >> > <toolchains> >> > <toolchain> >> > <type>jdk</type> >> > <provides> >> > <version>1.5</version> >> > <vendor>sun</vendor> >> > <id>default</id> >> > </provides> >> > <configuration> >> > <jdkHome>/usr/lib/jvm/java-6-sun</jdkHome> >> > </configuration> >> > </toolchain> >> > </toolchains> >> > Is there a reason for this requirement? What if I want to build it with >> > JDK >> > 1.6 instead of 1.5? In my mind, anything that makes it more difficult >> > for >> > people to build, the less likely they are to do so. I would think that >> > checking out the source from SVN and running "mvn install" should just >> > work. >> > Thanks, >> > Tauren >> > >> > >> > ------------------------------------------------------------------------------ >> > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> > Tap into the largest installed PC base & get more eyes on your game by >> > optimizing for Intel(R) Graphics Technology. Get started today with the >> > Intel(R) Software Partner Program. Five $500 cash prizes are up for >> > grabs. >> > http://p.sf.net/sfu/intelisp-dev2dev >> > _______________________________________________ >> > Joda-money-interest mailing list >> > Jod...@li... >> > https://lists.sourceforge.net/lists/listinfo/joda-money-interest >> > >> > >> >> >> ------------------------------------------------------------------------------ >> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> Tap into the largest installed PC base & get more eyes on your game by >> optimizing for Intel(R) Graphics Technology. Get started today with the >> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >> http://p.sf.net/sfu/intelisp-dev2dev >> _______________________________________________ >> Joda-money-interest mailing list >> Jod...@li... >> https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > |
From: Tauren M. <ta...@gr...> - 2010-12-03 14:51:04
|
Stephen, Fair enough -- you need to do what works best for you as the developer. My goal was simply to let you know that the build might not be working for others if you were assuming it was. I'm certainly no maven expert. I do wonder if it would be possible to use Maven Profiles to solve the problem. This way, you could have a consistent build by specifying a profile via the command line, an environment variable, or some other means. But for the average Joe who checks out the code, a default profile would be used that is more likely to work anywhere. http://maven.apache.org/guides/introduction/introduction-to-profiles.html I've never used profiles before, and perhaps there are better solutions. Not terribly important for a low profile project like this one, but it could be useful with joda-time. Thanks, Tauren On Fri, Dec 3, 2010 at 5:36 AM, Stephen Colebourne <sco...@jo...>wrote: > I find maven to be a right royal pain. Whatever I setup for me isn't > right for someone else. The toolchain code is to ensure that the built > version uses Java 5, which is necessary to get a consistent release > (as maven is useless at prducing reproducible builds). As far as I > know, this is the correct way to ensure that the build is Java 5, but > maybe there is a less intrusive way. > > Stephen > > > On 3 December 2010 07:22, Tauren Mills <ta...@gr...> wrote: > > I ran into some problems building Joda Money because it requires that I > have > > a ~/.m2/toolchains.xml file. I didn't have this file and had to research > > what it was and then create it. I have used Maven a lot, but never have > > happened upon this feature yet. > > When building, I got this error: > > > > 12/2/10 10:54:06 PM PST: [ERROR] Cannot find matching toolchain > definitions > > for the following toolchain types: > > jdk [ vendor='sun' version='1.5' ] > > 12/2/10 10:54:06 PM PST: Build errors for joda-money; > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > > goal org.apache.maven.plugins:maven-toolchains-plugin:1.0:toolchain > > (default) on project joda-money: Cannot find matching toolchain > definitions > > for the following toolchain types: > > jdk [ vendor='sun' version='1.5' ] > > Please make sure you define the required toolchains in your > > ~/.m2/toolchains.xml file. > > I didn't want to install JDK 1.5, so I faked it by adding a > toolchains.xml > > file that looks like this: > > <?xml version="1.0" encoding="UTF8"?> > > <toolchains> > > <toolchain> > > <type>jdk</type> > > <provides> > > <version>1.5</version> > > <vendor>sun</vendor> > > <id>default</id> > > </provides> > > <configuration> > > <jdkHome>/usr/lib/jvm/java-6-sun</jdkHome> > > </configuration> > > </toolchain> > > </toolchains> > > Is there a reason for this requirement? What if I want to build it with > JDK > > 1.6 instead of 1.5? In my mind, anything that makes it more difficult for > > people to build, the less likely they are to do so. I would think that > > checking out the source from SVN and running "mvn install" should just > work. > > Thanks, > > Tauren > > > > > ------------------------------------------------------------------------------ > > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > > Tap into the largest installed PC base & get more eyes on your game by > > optimizing for Intel(R) Graphics Technology. Get started today with the > > Intel(R) Software Partner Program. Five $500 cash prizes are up for > grabs. > > http://p.sf.net/sfu/intelisp-dev2dev > > _______________________________________________ > > Joda-money-interest mailing list > > Jod...@li... > > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > > > > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > |
From: Stephen C. <sco...@jo...> - 2010-12-03 13:36:44
|
I find maven to be a right royal pain. Whatever I setup for me isn't right for someone else. The toolchain code is to ensure that the built version uses Java 5, which is necessary to get a consistent release (as maven is useless at prducing reproducible builds). As far as I know, this is the correct way to ensure that the build is Java 5, but maybe there is a less intrusive way. Stephen On 3 December 2010 07:22, Tauren Mills <ta...@gr...> wrote: > I ran into some problems building Joda Money because it requires that I have > a ~/.m2/toolchains.xml file. I didn't have this file and had to research > what it was and then create it. I have used Maven a lot, but never have > happened upon this feature yet. > When building, I got this error: > > 12/2/10 10:54:06 PM PST: [ERROR] Cannot find matching toolchain definitions > for the following toolchain types: > jdk [ vendor='sun' version='1.5' ] > 12/2/10 10:54:06 PM PST: Build errors for joda-money; > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-toolchains-plugin:1.0:toolchain > (default) on project joda-money: Cannot find matching toolchain definitions > for the following toolchain types: > jdk [ vendor='sun' version='1.5' ] > Please make sure you define the required toolchains in your > ~/.m2/toolchains.xml file. > I didn't want to install JDK 1.5, so I faked it by adding a toolchains.xml > file that looks like this: > <?xml version="1.0" encoding="UTF8"?> > <toolchains> > <toolchain> > <type>jdk</type> > <provides> > <version>1.5</version> > <vendor>sun</vendor> > <id>default</id> > </provides> > <configuration> > <jdkHome>/usr/lib/jvm/java-6-sun</jdkHome> > </configuration> > </toolchain> > </toolchains> > Is there a reason for this requirement? What if I want to build it with JDK > 1.6 instead of 1.5? In my mind, anything that makes it more difficult for > people to build, the less likely they are to do so. I would think that > checking out the source from SVN and running "mvn install" should just work. > Thanks, > Tauren > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > |
From: Tauren M. <ta...@gr...> - 2010-12-03 07:22:15
|
I ran into some problems building Joda Money because it requires that I have a ~/.m2/toolchains.xml file. I didn't have this file and had to research what it was and then create it. I have used Maven a lot, but never have happened upon this feature yet. When building, I got this error: 12/2/10 10:54:06 PM PST: [ERROR] Cannot find matching toolchain definitions for the following toolchain types: jdk [ vendor='sun' version='1.5' ] 12/2/10 10:54:06 PM PST: Build errors for joda-money; org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-toolchains-plugin:1.0:toolchain (default) on project joda-money: Cannot find matching toolchain definitions for the following toolchain types: jdk [ vendor='sun' version='1.5' ] Please make sure you define the required toolchains in your ~/.m2/toolchains.xml file. I didn't want to install JDK 1.5, so I faked it by adding a toolchains.xml file that looks like this: <?xml version="1.0" encoding="UTF8"?> <toolchains> <toolchain> <type>jdk</type> <provides> <version>1.5</version> <vendor>sun</vendor> <id>default</id> </provides> <configuration> <jdkHome>/usr/lib/jvm/java-6-sun</jdkHome> </configuration> </toolchain> </toolchains> Is there a reason for this requirement? What if I want to build it with JDK 1.6 instead of 1.5? In my mind, anything that makes it more difficult for people to build, the less likely they are to do so. I would think that checking out the source from SVN and running "mvn install" should just work. Thanks, Tauren |
From: Stephen C. <sco...@jo...> - 2010-01-06 02:16:12
|
Thanks. I'll try to improve it for the next release. Stephen 2010/1/4 Rob Purcell <rob...@gm...>: > Hi Stephen, > I can appreciate your reluctance to fiddle with Maven. In this case I think > things are pretty straightforward, however. You've already got: > <source>1.5</source> > <target>1.5</target> > in your pom.xml, which gets you almost there. This isn't completely correct > if your default JDK is not 1.5. In that case, adding: > > <compilerArgument>-verbose -bootclasspath > ${java.home}\lib\rt.jar</compilerArgument> > > Would complete the picture (with true cross-compilation to Java 1.5 when > java.home points to JDK 1.5). Just out of interest, I compared the classes > produced from JDK1.5 and 1.6 (on Windows) and the bytecode is identical even > without the extra compilerArgument. > Alternatively, you might like to check this > out: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html > as this identifies another approach for solving the issue. > Hope that's at least of some interest. > Cheers, > Rob > > On 3 Jan 2010, at 22:24, Stephen Colebourne wrote: > > Thanks, I understand that the C: causes issues, but I need to release > the library as 1.5 specific I'd need to waste more time on maven to > try and find another solution... > Stephen > > 2010/1/2 Rob Purcell <rob...@gm...>: > > Hi, > > Having an initial look at the Joda Money library. Noticed that there's a > slightly machine-specific element for maven-compiler-plugin in the pom.xml: > > <executable>C:\java\jdk1.5.0\bin\javac</executable> > > Needless to say, this isn't particularly Mac-friendly! > > I think this entry is actually unnecessary (unless you're really after a > very specific version of Java, which seems unlikely), and removing it > completely allows successful compilation on JDK 1.6.0_017 on Snow Leopard. > > Cheers, > > Rob > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > Joda-money-interest mailing list > > Jod...@li... > > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > > |
From: Rob P. <rob...@gm...> - 2010-01-04 22:54:59
|
Hi Stephen, I can appreciate your reluctance to fiddle with Maven. In this case I think things are pretty straightforward, however. You've already got: <source>1.5</source> <target>1.5</target> in your pom.xml, which gets you almost there. This isn't completely correct if your default JDK is not 1.5. In that case, adding: <compilerArgument>-verbose -bootclasspath ${java.home}\lib\rt.jar</compilerArgument> Would complete the picture (with true cross-compilation to Java 1.5 when java.home points to JDK 1.5). Just out of interest, I compared the classes produced from JDK1.5 and 1.6 (on Windows) and the bytecode is identical even without the extra compilerArgument. Alternatively, you might like to check this out: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html as this identifies another approach for solving the issue. Hope that's at least of some interest. Cheers, Rob On 3 Jan 2010, at 22:24, Stephen Colebourne wrote: > Thanks, I understand that the C: causes issues, but I need to release > the library as 1.5 specific I'd need to waste more time on maven to > try and find another solution... > Stephen > > 2010/1/2 Rob Purcell <rob...@gm...>: >> Hi, >> >> Having an initial look at the Joda Money library. Noticed that there's a slightly machine-specific element for maven-compiler-plugin in the pom.xml: >> >> <executable>C:\java\jdk1.5.0\bin\javac</executable> >> >> Needless to say, this isn't particularly Mac-friendly! >> >> I think this entry is actually unnecessary (unless you're really after a very specific version of Java, which seems unlikely), and removing it completely allows successful compilation on JDK 1.6.0_017 on Snow Leopard. >> >> Cheers, >> Rob >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Joda-money-interest mailing list >> Jod...@li... >> https://lists.sourceforge.net/lists/listinfo/joda-money-interest >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest |
From: Stephen C. <sco...@jo...> - 2010-01-03 22:24:26
|
Thanks, I understand that the C: causes issues, but I need to release the library as 1.5 specific I'd need to waste more time on maven to try and find another solution... Stephen 2010/1/2 Rob Purcell <rob...@gm...>: > Hi, > > Having an initial look at the Joda Money library. Noticed that there's a slightly machine-specific element for maven-compiler-plugin in the pom.xml: > > <executable>C:\java\jdk1.5.0\bin\javac</executable> > > Needless to say, this isn't particularly Mac-friendly! > > I think this entry is actually unnecessary (unless you're really after a very specific version of Java, which seems unlikely), and removing it completely allows successful compilation on JDK 1.6.0_017 on Snow Leopard. > > Cheers, > Rob > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest > |
From: Rob P. <rob...@gm...> - 2010-01-02 11:42:30
|
Hi, Having an initial look at the Joda Money library. Noticed that there's a slightly machine-specific element for maven-compiler-plugin in the pom.xml: <executable>C:\java\jdk1.5.0\bin\javac</executable> Needless to say, this isn't particularly Mac-friendly! I think this entry is actually unnecessary (unless you're really after a very specific version of Java, which seems unlikely), and removing it completely allows successful compilation on JDK 1.6.0_017 on Snow Leopard. Cheers, Rob |
From: Stephen C. <sco...@jo...> - 2009-11-30 22:55:22
|
phil. wrote: > I like the idea of FixedScaleMoney and VariableScaleMoney. It's really > much easier to understand what it's supposed to be. What does > ZeroScaleMoney mean? A BigInteger based Money with a unit of cents > instead of dollars or euros? I might add a fixed scale money that you have to configure the scale on construction. Money and BigMoney would still be useful though. >>>> Money#equals(Object) >> I think the principle of least surprise would indicate that USD 10 == USD 10.00? It doesn't for BigDecimal and the number of bugs caused by it is huge. >> > This only causes that many bugs because people tend to not understand > that 10.00 is more precise then 10. I'm going to leave USD 10 != USD 10.00. For Money and a new FixedScaleMoney the issue wouldn't arise anyway, and BigMoney is intended for more advanced users. Seems like a fair balance. Stephen |
From: phil. <w97...@sn...> - 2009-11-23 22:04:02
|
Gareth Davis gareth-at-logicalpractice.com |sourceforge.net| wrote: > On 19 Nov 2009, at 08:17, Stephen Colebourne wrote: > > >> 2009/11/18 Gareth Davis <ga...@lo...>: >> >>> Money/BigMoney >>> ============== >>> Looks a little confusing, not sure if this is just mid refactoring... but only one would be fine (backed by BigDecimal) >>> >> The classes have different purposes and APIs. Money fixes the decimal >> places to the currencies scale, BigMoney can have any scale. >> >> > ah... I see it kinda of looks at first glance that BigMoney is meant to be a higher capacity implementation of Money. It may just be a naming issue...VariableScaleMoney, Maybe Money should just be a interface and you could have flavours FixedScaleMoney & VariableScaleMoney - ZeroScaleMoney (some applications actually do have that policy) > I like the idea of FixedScaleMoney and VariableScaleMoney. It's really much easier to understand what it's supposed to be. What does ZeroScaleMoney mean? A BigInteger based Money with a unit of cents instead of dollars or euros? > >>> Money#equals(Object) >>> ==================== >>> Currently is scale aware i.e. USD 30 != USD 30.00 this really isn't representative of real monetary amounts and is one of the reasons that using a raw BigDecimal for monetary amounts is a pain. I would suggest that if the Money represents the same amount of a currency it is equal to another regardless of the internal scale (ie. be based on BigDecimal#compareTo) >>> >>> The gotcha with this is that the hashCode of BigDecimal as includes the scale. >>> >> Money has a fixed scale, so this doesn't occur as an issue. >> >> For BigMoney its more of a problem. I have defined equals as "you can >> take this object and replace it by an equals() object and see no >> changes in your application". I like that definition. >> >> > I see ... it a little problematic. BigMoney's divide operations are I guess the issue, they assume the scale of the of the current object which would be where it could break if the above was implemented. The alternate is to make the divide operations have a mandatory scale parameter, when ever dividing money. I realise this is different to BigDecimal, but again it's one of the reasons why BigDecimal isn't the best thing for money values. > > I think the principle of least surprise would indicate that USD 10 == USD 10.00? It doesn't for BigDecimal and the number of bugs caused by it is huge. > This only causes that many bugs because people tend to not understand that 10.00 is more precise then 10. In theory, USD 10 is not the same as USD 10.00 because USD 10 is rounded to the nearest dollar while USD 10.00 is rounded to the nearest cent. So USD 10 is actually short for the range [USD 9.50, USD 10.49] and USD 10.00 is only a part of that range. That's why USD 10 is not equal to USD 10.00. In practice this shouldn't be a problem as well, since usually when handling money you have a fixed scale for calculations and can use equals(). If you want to compare USD 10 and USD 10.00, this might be an indication that a) the requirements are not that sound and b) the USD 10 were rounded to early which is a potential rounding error. And if you really have a valid reason to compare the two... well, just use compare() ;-). > > >>> Zero money >>> ========== >>> This is a more radical suggestion and that is that zero doesn't have a currency. This may seem completely nuts but bare with me. The reasoning for this is quite simple in the real world nothing is well nothing, if somebody has 0 pounds... it is exactly the same. >>> >> I'll have to spend longer thinking about this... >> >> > it a bit controversial this one, I'm by no means 100% certain that it's correct but I've also seen painful null handling in several real applications that have currencies in zero. Maybe views from a wider audience would help. > Let's say you want to sum up a list of monies and you initialise it with this "zero of whatever", but the list happens to be empty. So the sum is "zero of whatever". Now you add that to EUR 20.00. This is kind of the same as adding null, isn't it. There is no currency check. And that's just not right :-). Or a mistake I actually made: The list contained some monies. Due to a bug those were USD instead of EUR. Because of the "zero of whatever" initialisation, the sum was happily built and written into the database for later processing. Another application read the sum from the database and crashed when it tried to add the sum in USD to a money in EUR. The cause of this bug was really hard to find. I rewrote Money to not allow "zero of whatever" and as it turned out, in 99% of all cases it was possible to initialise the zero money with a proper currency and for the remaining 1% null handling was necessary but not that painful. So if it were up to me, I'd definitely would not allow "zero of whatever". Cheers, George |
From: Stephen C. <sco...@jo...> - 2009-11-23 00:54:33
|
Den Orlov wrote: > Do you have any plans to collaborate with JSR-275 group > (http://www.javaworld.com/javaworld/jw-10-2007/jw-10-jsr275.html?page=4) I have no immediate plans to do so. Joa-Money is a library that should have no dependencies. Stephen |
From: Gareth D. <ga...@lo...> - 2009-11-22 12:39:57
|
On 19 Nov 2009, at 08:17, Stephen Colebourne wrote: > 2009/11/18 Gareth Davis <ga...@lo...>: >> Money/BigMoney >> ============== >> Looks a little confusing, not sure if this is just mid refactoring... but only one would be fine (backed by BigDecimal) > > The classes have different purposes and APIs. Money fixes the decimal > places to the currencies scale, BigMoney can have any scale. > ah... I see it kinda of looks at first glance that BigMoney is meant to be a higher capacity implementation of Money. It may just be a naming issue...VariableScaleMoney, Maybe Money should just be a interface and you could have flavours FixedScaleMoney & VariableScaleMoney - ZeroScaleMoney (some applications actually do have that policy) > >> Money#equals(Object) >> ==================== >> Currently is scale aware i.e. USD 30 != USD 30.00 this really isn't representative of real monetary amounts and is one of the reasons that using a raw BigDecimal for monetary amounts is a pain. I would suggest that if the Money represents the same amount of a currency it is equal to another regardless of the internal scale (ie. be based on BigDecimal#compareTo) >> >> The gotcha with this is that the hashCode of BigDecimal as includes the scale. > > Money has a fixed scale, so this doesn't occur as an issue. > > For BigMoney its more of a problem. I have defined equals as "you can > take this object and replace it by an equals() object and see no > changes in your application". I like that definition. > I see ... it a little problematic. BigMoney's divide operations are I guess the issue, they assume the scale of the of the current object which would be where it could break if the above was implemented. The alternate is to make the divide operations have a mandatory scale parameter, when ever dividing money. I realise this is different to BigDecimal, but again it's one of the reasons why BigDecimal isn't the best thing for money values. I think the principle of least surprise would indicate that USD 10 == USD 10.00? It doesn't for BigDecimal and the number of bugs caused by it is huge. >> Zero money >> ========== >> This is a more radical suggestion and that is that zero doesn't have a currency. This may seem completely nuts but bare with me. The reasoning for this is quite simple in the real world nothing is well nothing, if somebody has 0 pounds... it is exactly the same. > > I'll have to spend longer thinking about this... > it a bit controversial this one, I'm by no means 100% certain that it's correct but I've also seen painful null handling in several real applications that have currencies in zero. Maybe views from a wider audience would help. >> PS I have a couple of patches for the current trunk (just compile stuff) would you like them posted to this list? > 2902028 - JDK 1.6 compile fix is one of mine 2899206 - Is a dup of the other patch I was going to submit. Although I'd suggest the compiler config is moved to a profile rather than deleted. > Patches are best as tracker issues in the sourceforge tracker. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Joda-money-interest mailing list > Jod...@li... > https://lists.sourceforge.net/lists/listinfo/joda-money-interest |
From: Stephen C. <sco...@jo...> - 2009-11-19 08:17:58
|
2009/11/18 Gareth Davis <ga...@lo...>: > Money/BigMoney > ============== > Looks a little confusing, not sure if this is just mid refactoring... but only one would be fine (backed by BigDecimal) The classes have different purposes and APIs. Money fixes the decimal places to the currencies scale, BigMoney can have any scale. > Money#equals(Object) > ==================== > Currently is scale aware i.e. USD 30 != USD 30.00 this really isn't representative of real monetary amounts and is one of the reasons that using a raw BigDecimal for monetary amounts is a pain. I would suggest that if the Money represents the same amount of a currency it is equal to another regardless of the internal scale (ie. be based on BigDecimal#compareTo) > > The gotcha with this is that the hashCode of BigDecimal as includes the scale. Money has a fixed scale, so this doesn't occur as an issue. For BigMoney its more of a problem. I have defined equals as "you can take this object and replace it by an equals() object and see no changes in your application". I like that definition. > Zero money > ========== > This is a more radical suggestion and that is that zero doesn't have a currency. This may seem completely nuts but bare with me. The reasoning for this is quite simple in the real world nothing is well nothing, if somebody has 0 pounds... it is exactly the same. I'll have to spend longer thinking about this... > PS I have a couple of patches for the current trunk (just compile stuff) would you like them posted to this list? Patches are best as tracker issues in the sourceforge tracker. |
From: Gareth D. <ga...@lo...> - 2009-11-18 22:30:03
|
hi, I've been looking at joda-money with some interest and I would like to offer a bit of feedback: Money/BigMoney ============== Looks a little confusing, not sure if this is just mid refactoring... but only one would be fine (backed by BigDecimal) Money#equals(Object) ==================== Currently is scale aware i.e. USD 30 != USD 30.00 this really isn't representative of real monetary amounts and is one of the reasons that using a raw BigDecimal for monetary amounts is a pain. I would suggest that if the Money represents the same amount of a currency it is equal to another regardless of the internal scale (ie. be based on BigDecimal#compareTo) The gotcha with this is that the hashCode of BigDecimal as includes the scale. Zero money ========== This is a more radical suggestion and that is that zero doesn't have a currency. This may seem completely nuts but bare with me. The reasoning for this is quite simple in the real world nothing is well nothing, if somebody has 0 pounds... it is exactly the same. There are a couple of side benefits certain benefits to how the code looks: The totalling loop Money total; for ( Money m : monies ) total = total != null ? total.plus(m) : total; becomes simpler: Money total = Money.ZERO for ( Money m : monies ) total = total.plus(m) ; And methods the are null safe can return zero when with out having a currency. public static Money nullSafe(Money m){ return m != null ? m : Money.ZERO } or public static Money min(Money m1, Money m2){ if ( m1 == null && m2 == null ){ return ZERO } // } There are obviously some down sides. All those plus(int,double,BigDecimal) method would be possible any longer because Money.ZERO.plus(55) would be in what currency? This IMHO isn't so bad... I tend to see (in my experience) summation of monetary amounts with other monetary amounts rather than with non monetary values in doubles etc. Hope I haven't rambled on too much. Gareth Davis www.logicalpractice.com PS I have a couple of patches for the current trunk (just compile stuff) would you like them posted to this list? |
From: Den O. <den...@gm...> - 2009-11-17 12:21:59
|
Hi, Do you have any plans to collaborate with JSR-275 group (http://www.javaworld.com/javaworld/jw-10-2007/jw-10-jsr275.html?page=4) Den |
From: Stephen C. <sco...@jo...> - 2009-08-26 22:58:25
|
Benoit Xhenseval wrote: > · It can handle replacement currencies: e.g. old Turkish Lira to > New Turkish Lira; Belgian Franc to Euro where the rate from old to new > is a FIXED conversion rate. I wasn't planning any support for the data of conversion rates. > 2. It seems that there are a few dependencies which I’d prefer to > see separated: Money -> CurrencyUnit -> CurrencyUnitDataProvider. I > feel that the provider should NOT be referenced in the CurrencyUnit. I’d > prefer to have Money & CurrencyUnit as a ‘set’. I'm not sure I follow your goal. I want to ensure that the user cannot just create any arbitrary currency. This means that currencies must be registered in advance, which I've made pluggable by the provider. I'm not sure how you'd make CurrencyUnit not depend on the provider. > 3. CurrencyUnitDataProvider should be replaceable as many Banks > will have their own data source and will NOT trust anything else; > furthermore, currencies do change quickly and doing a new release for > this is simply not possible in most cases (eg the introduction of the > new Turkish Lira should not require the release of a new version of the > application). Specifying a system property replaces the provider. > 4. The current library would not work very well in a distributed > environment if the CurrencyUnitDataProvider is tailored. For instance, > say that the server side has its own CurrencyUnitDataProvider that is > hooked to the database. If Money is serialised and sent to a GUI which > DOES NOT have access to the DB, it will TRANSPARENTLY revert to use the > default CSV file provided by Joda-money. There should be a mechanism > whereby the serialization could take the data as-is from the server. > This is also a problem if client and server are using different versions > of joda-money. > So I would drop the readResolve mechanism and accept the serialised version. Possible, but then there is a mechanism to create currency instances that don't match those that are registered. I see the point though - its rather like time zone rules. > 5. As such, I’d suggest to move the CurrencyUnit .of(Locale...) > somewhere else as this is depending on data that could be coming from > different provider Not sure why moving it to another location would be helpful. > 6. The storage of the actual value as a long is quite ingenious > BUT it is very likely that getAmount is going to be called many times > and therefore I’d suggest to keep the result once calculated. Possible. I suspect most money objects will be short lived. > 7. I would suggest to make the Money class more ‘null-resistent’ > eg why not returning this if someone calls Money.plus(null) (for > BigDecimal). It would make life easier when doing many calculations. MoneyUtils provides null-safe operations. Making Joda-Time null-safe was a mistake I think. > 8. Should the CurrencyUnit have the long name for the > currency...eg do you know what AED is? The problem is that this data isn't available from the JDK until JDK7. Now ideally we should get the names from CLDR (along with other stuff), but that involves a bit of XML parsing that doesn't greatly excite me right now. Feel free to dive in though. > 9. Should the CurrencyUnit have a ‘replacement’ currency with a > conversion factor? This is very useful when a currency is changed; e.g. > DEM to EUR and the conversion rate is a BigDecimal of “0. 51129” CLDR has currency history info, but not conversion rates. I want to avoid conversion rates. > 10. I have never heard of Currencies with a numeric code, it is > non-standard, probably something for your project. It seems to introduce > 2 keys for a currency with the potential inconsistencies. Only the > String code is used as key in the code. The numeric code is part of the ISO standard. > 11. On style, I quite like using final as much as possible... Eclipse > can enforce that. I find it quite intrusive :-) Stephen |