Skip to main content

[JSR-354] Re: SE, ME, EE or what

  • From: Stephen Colebourne <scolebourne@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: SE, ME, EE or what
  • Date: Mon, 28 Jan 2013 22:33:37 +0000

On 28 January 2013 21:22, Jeremy <jerdavies@...> wrote:
> I recently joined the EG on JSR-354. I agree with your points but can you
> clarrify what you mean by:
>
> it is vital that users write  Money m = Money.of(...) and not  Monetary m =
> Money.of(...) This is necessary to ensure the objects passed about are
> immutable and behave correctly.
>
> How does this have a bearing  on the immutable object contract? Passing the
> concrete object around, not the interface does not feel right but I'm
> guessing this is specific to the "money" example mentioned.

Imagine you write a method performing money calculations. You have three 
options

public Money process(Money)
public Money process(Monetary)
public Monetary process(Monetary)

The second two suffer from the problem that in Java, an interface (or
abstract class) guarantees you nothing. Only a class has the
guarantees you need wrt immutability. (An interface can specify that
implementations should be immutable, but it cannot guarantee it.)

The return type should also be a concrete class, again to ensure that
users know what they are getting.

A classic example of this going wrong is BigDecimal. That is a class,
but it is not final. Most users writing an API with a setter method
accepting a BigDecimal and storing it in an instance variable will
simply assign the object to the internal state. But this is a security
hole and potential bug. The user of the the API can maliciously pass
in a BigDecimal subclass and gain access they shouldn't. Given the
sensitive nature of most money calculations, this must be avoided.

As an aside, part of this is knowledge from experience. JSR-310
originally had interfaces like DateProvider and TimeProvider that were
used as the inputs to most methods as a means of flexibility for
users. This turned out to be a hugely bad idea. The examples would
take a long time to work through, but in summary the problem was that
DateProvider would only take the LocalDate part of an object, whereas
the object you were passing to the method might be something more
complex, like a date-time with time-zone. What happened was that you
looked at a piece of code and thought it would take the date, time and
time-zone from the input object, where in fact it was only taking the
date. This design of flexible inputs turns out to be a similar one to
Scala's implicits, which are frequently too lenient.

The above describes why you want methods to generally be quite
specific, and the same applies to local variables. The Java code we
are going to be writing going forward will be increasingly parallel. A
Monetary interface object can provide no real guarantees about how it
will behave in parallel, whereas an honest, clean immutable value type
is crystal clear.


On 28 January 2013 22:18, Werner Keil <werner.keil@...> wrote:
> Sorry, but assuming Money is a concrete class implementing a Monetary
> interface, this is bullshit, and the person who recommends using interfaces
> over classes isn't just me but Josh Bloch in his book  Effective Java (he
> also was main author of some of the more easily to extend parts of the JDK
> like Collection API)

This is why I listed in my previous email that it is important to
understand that designing this API is very different to designing a
typical enterprise API, or even Collections. These types
(date/money/currency) are only one level above Integer and String.
They have to perform in the same way, and that means that they have
very a different API style. Josh Bloch's guidelines are more intended
for general API design, not value type design. He also says "favour
composition over inheritence".

Stephen


[JSR-354] SE, ME, EE or what

Tresch Anatole (KFSC 225) 01/28/2013

[JSR-354] Re: SE, ME, EE or what

Stephen Colebourne 01/28/2013

[JSR-354] Re: SE, ME, EE or what

Werner Keil 01/28/2013

[JSR-354] Re: SE, ME, EE or what

Jeremy 01/28/2013

[JSR-354] Re: SE, ME, EE or what

Werner Keil 01/28/2013

[JSR-354] Re: SE, ME, EE or what

Stephen Colebourne 01/28/2013

[JSR-354] Re: SE, ME, EE or what

Werner Keil 01/28/2013

[JSR-354] Re: SE, ME, EE or what

Jeremy 01/29/2013

[JSR-354] Re: SE, ME, EE or what

Stephen Colebourne 01/29/2013

[JSR-354] Re: SE, ME, EE or what

Jeremy 01/29/2013
 
 
Close
loading
Please Confirm
Close