[JSR-354] Re: TCK tests finished in a first release
- From: "Tresch, Anatole " <anatole.tresch@...>
- To: "jcurrency_mail@..." <jcurrency_mail@...>
- Subject: [JSR-354] Re: TCK tests finished in a first release
- Date: Tue, 10 Jun 2014 14:51:23 +0000
- Accept-language: de-CH, en-US
OK summarizing we will stick on ArithmeticException then. JDK compatibility
is important and I do not have a problem with that. So I will adapt the
TCK/RI next days (e.g. during the DevoXX) and ensure the spec is clear on
Thanks for your feedback!
From: Werner Keil [mailto:werner.keil@
Sent: Donnerstag, 5. Juni 2014 18:30
Subject: [JSR-354] Re: TCK tests finished in a first release
Math/StrictMath are areas, where JSR 363 EG Member Martin provided fixes and
improvements to Java 8[cid:image001.gif@01CF84CC.35F112E0]
There are places in the JSR 363 RI like intValue(Unit) where we also throw
ArithmeticException rather than MeasurementException or a specialized form.
And in at least one case, a Checked Exception in the API also doesn't inherit
from MeasurementException, which uses
On Thu, Jun 5, 2014 at 6:08 PM, Stephen Colebourne
JSR-310 uses ArithmeticException for overflows. This is encoded into
the new methods added to the Math class in JDK 8. I'd strongly suggest
that MonetaryException isn't what you want here.
On 4 June 2014 07:19, Anatole Tresch <atsticks@...<mailto:atsticks@
> Dear all,
> just wanted to inform you that I have all TCK tests implemented so far. I
> will have to go over the TCK again, e.g. during some Hackergarten events and
> add more test messages and more detailed Javadoc. Also the TCK must be
> repackaged, so it can be easily combined with an arbitrary implementation
> and yes, there must be some TCK guide written (already started in asciidoc).
> But I think this is an important step.
> Also with the current RO all test now run green.
> From the code side there is basically only one small adaptation on the spec,
> I would propose:
> Currently the spec defines at some locations that MonetaryAmount
> implementation must throw an ArithemticException, when the amounts operated
> exceed the internal capabilities. I would suggest to change this to throw a
> MonetaryException instead of. It makes life easier for developers, because
> they can focus on catching MonetaryException only and do not need to have
> know how in where an ArithemticException may be thrown or not. Additionally
> it is also clear, that when a MonetaryException is thrown it must have its
> origin in the money API, which makes analysis simpler.
> Anatole Tresch
> Java Lead Engineer, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
> Switzerland, Europe Zurich, GMT+1
> Twitter: @atsticks
> Blogs: http://javaremarkables.blogspot.ch/
> Google: atsticks
> Mobile +41-76 344 62 79<tel:%2B41-76%20344%2062%2079>