Skip to main content

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

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: SE, ME, EE or what
  • Date: Mon, 28 Jan 2013 23:18:28 +0100

Jez/Stephen/all,

I'll reply to the thread Anatole initiated in a little while, but let me add something here.

On Mon, Jan 28, 2013 at 10:22 PM, Jeremy <jerdavies@...> wrote:
Hi Stephen,

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.


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)

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.

Also, thanks for all your work with the joda libraries over the years. Great
stuff :)

Cheers,

Jez


Cheers,
Werner
 
-----Original Message-----
From: jodastephen@... [mailto:jodastephen@...] On Behalf Of
Stephen Colebourne
Sent: 28 January 2013 14:36
To: jcurrency_mail@...
Subject: [JSR-354] Re: SE, ME, EE or what

Firstly, it is important to understand that there are two types of JSR.
Those that define specs in Java EE or Java ME, and those that are a
process-oriented shim on top of alterations to the JDK (Project Coin,
Lambda, 310 etc).

These two types of JSR are utterly different. The former typically consist
of interfaces, and the purpose of the spec writer is to allow multiple
organizations/companies to implement the specs in competition eg JMS,
Servlet. The latter (JDK) is not really a spec at all. Oracle have proven
beyond all doubt that no-one else will be permitted to implement Java SE.
Thus it is not a spec, but an implementation with well-defined Javadoc.

The next key point to understand is that value types change how the code
should be worked with. It is vitaly important that work with concrete types,
not with interfaces users. Assuming Money is a value type class and Monetary
is the interface, 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.

Thus, the key design realisation is that the interfaces are secondary to the
value types. The interfaces only exist to allow multiple value types to
interoperate, but not to detract from the value types.

Thus, translating from JSR-310, there should be a method
 Money.from(Monetary)
which allows anyone that has implemented the interface to convert their
implementation to the standard value type.

It could be argued that you could start from the interfaces and then define
implementations that match. But my point is that is backwards.
It is vital to start from the value types and then wrap interfaces around
them.

Stephen


On 28 January 2013 14:19, Tresch Anatole (KFSC 225)
<anatole.tresch@...> wrote:
>
> Dear Colluegues
>
>
>
> Please calm down a bit. I do not want to estimate or judge any of your
statements, but I would like to encourage you both, to focus on this JSR.
For me the question is, to what persons we should talk to come to clearer to
a stetament what a SE specification really must contain and what not.
>
> Perhaps this JSR also shows to by a hybrid one not only in case of
> targeting SE and optionally ME, but also regarding SE and extensions
> (possibly included in a EE part)…
>
>
>
> Basically since it matches on all variants, it is a good hint, that SE is
not so a bad target. Finally the core part can be fully implemented by the
JDK as a starting point, e.g. by using BigDecimal for numeric values and
util.Currency for currencies. If this is required, we have to move that code
from the RI into the spec part, there is nothing easier than that. Or Oracle
will provide its own implementation… Summarizing I do not see a problem, but
we definitively have to start talking with some colluegues at Oracle when
the renewal ballot is over.
>
>
>
> And finally we still have an EDR before us, we are not yet required to
have the final version ready then. I assume we could add such aspects as an
appendix to our EDR publication, so we can also take feedback from the
community on this topic.
>
>
>
> Thank you very much and again: peace please!
>
>
>
> Regards,
>
>
>
> Anatole Tresch
>
> CREDIT SUISSE AG
>
> Information Technology | Java Core Framework & Support, KSXK 23
>
> Zollstrasse 20/36 | 8070 Zürich | Switzerland
>
> Phone +41 44 334 03 89
>
> anatole.tresch@... | www.credit-suisse.com
>
>
>
> From: Werner Keil [mailto:werner.keil@...]
> Sent: Monday, January 28, 2013 14:54
> To: jcurrency_mail@...
> Subject: [JSR-354] Re: JSR-310 - was Re: Re: Value types
>
>
>
> Stephen,
>
>
>
> I meet with people from Oracle quite often or have conversations.
>
> And the general understanding is, that "ideas and improvements from
Oracle" were more a complete redesign.
>
>
>
> You or the 2 other Spec Leads, Roger ultimately will also have to fix the
issues, JDK Platform Architects like Brian Goetz, Mark Reinhold and others
found, especially the "myriad of redundant getXXX() methods" just to name
one of them.
>
>
>
> We'll base parts of 354 that are targeted at Java SE (9) on the result of
these improvements, regardless whether you or Roger (SCM logs mostly show
traces of him though in OpenJDK, all you're visible on is that
"org.threeten" backport, I don't really see a great point in, but the
community may prove me wrong on that) actually commit to OpenJDK.
>
>
>
> You are lucky 310 was started long before JCP.next regulations, as a vast
majority of EC Members, not me alone would have declared it Dormant or
requested Spec Lead change.
>
> Well, Oracle handled that it's way by having Roger step in and do the
> work now
>
>
>
> Werner
>
> On Mon, Jan 28, 2013 at 2:46 PM, Stephen Colebourne <scolebourne@...>
wrote:
>
> On 28 January 2013 13:33, Werner Keil <werner.keil@...> wrote:
> >> 2) Is the design modelled on JSR-310?
> >> 310 is defining the design space of immutable value types in the JDK.
> >> Not following the design relatively closely would be a mistake, and
> >> may be resisted by Oracle at the point of integration.
> >
> > 310 defined nothing, compliant or welcome by the JDK or Oracle I'm
afraid.
> > The massively refactored results you see in "java.time" driven by
> > the 3rd Spec Lead Roger Riggs has practically no similarity with the
> > old "javax.time" once found at GitHub which is now all dead code and
irrelevant.
>
> Werner, this is FUD that you have been repeating in numerous forums.
> The JSR-310 design has been continuously evolving and I have been at
> the centre of all the design decisions. The code in OpenJDK is my
> code, supplemented with ideas and improvements from Oracle.
>
> The code at GitHub is old simply because active development moved to
> OpenJDK as part of integration. The process was entirely continuous.
> There was no replacement by an alternate set of Oracle-approved code.
>
> Please stop repeating your nonsense.
> Stephen
>
>
>
>
>
> --
>
> Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead,
> Babel Language Champion | Java Godfather
>
> Twitter @wernerkeil | @JSR354 | #Java_Social | #EclipseUOMo | #OpenDDR
>
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
>
>
> * Nordic Java NightHacking: January 31 2013, Copenhagen, Denmark.
> Werner Keil, JCP Executive Committee Member welcomes Stephen Chin's
> "Nordic NightHacking Tour" in Copenhagen
>
>
>
> * Social Media Week: February 18 2013, Hamburg, Germany. Werner Keil, JCP
Executive Committee Member, Agorava Co-Founder will present "Enterprise
Social using Open Source Frameworks like Agorava"



[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