Use Advanced Search to search the entire archive.
Re: Proposal
- From: Otávio Gonçalves de Santana <
>
- To:
- Subject: Re: Proposal
- Date: Mon, 17 Nov 2014 07:56:35 -0200
Werner, it is the problem, no make sense do the same stuff to different
JSR, because the goal is different, now we are looking for ME platform.
And Yes, it impact in the size, we have, for example, 4 implementations for
Unit, 5 classes in internal and classes that do the validation and make
another unit, for example, Length divided for Time results in Speed.
Another problem is power processor to validate this think.
I not saying to remove directly, just use as lib and/or as framework to get
more modularity.
On Mon, Nov 17, 2014 at 2:14 AM, Werner Keil
<
>
wrote:
>
Hello all,
>
>
IMHO it'll considerably remove usefulness from both. There's practically
>
no difference in size added by 2 methods in Quantity nor in Unit.
>
>
I was on the MEEP EG and the only real way we could further improve
>
minimal size for tiniest ME devices is to break the API into one JAR per
>
package. The new structure with 3 of those at the moment would make that
>
rather simple compared to MEEP. And for SE/EE we can offer a "convenience"
>
all in one JAR.
>
>
JSRs like especially 354 offer similar methods on an API level to users.
>
They are bound to SE only by Lamdas, but unlike Jigsaw/Module JSR (Yes,
>
there should be one, but likely never for ME;-) it might come to ME with V9
>
or so, then a JavaMoney implementation is possible on at least a bit larger
>
devices, too.
>
>
Furthermore especially on Quantity (which they called Measurement, we
>
moved the "measuring" part to implementations because that allows adding
>
say JSR 310, etc. but in theory the slim Measurement interface with 2
>
getters could also be added to the API in future;-) existing Measurement
>
APIs like OSGi Measurement offer divide/multiply operations. If we crippled
>
the API, a vast majority of projects interested in adopting JSR 363 would
>
either stick with the defunct 275 (e.g. if we provided no real improvement
>
over it, which alone a clear API/RI separation already does;-) or those
>
OSGi "enhancements" especially in the Eclipse or Embedded world.
>
>
It wouldn't be enough to cripple the API and leave just 2 operations away
>
to say offer Jean-Marie and JScience a freedom to call it times/divide
>
instead of multiply/divide. He also suggested plus/minus instead of
>
add/subtract;-)
>
>
I would however rather rename those on an API level creating a slight
>
inconsistency with everything in the Java world that does this except the
>
"Alien" JSR 310 where operations have a weird, inconsistent mix of Scala,
>
Ruby or Groovy naming for these basic arithmetic operations.
>
>
Everything else from BigDecimal to OSGi (slightly abbreviated as div/mul,
>
but nowadays descriptive method names are often better than ultra short
>
ones thanks to auto-completion and new compilers:-) JavaMoney or JavaFX
>
calls them the same consistent way.
>
>
Werner
>
Am 17.11.2014 03:49 schrieb "Martin Desruisseaux" <
>
>:
>
>
Hello Otavio
>
> Le 17/11/14 11:05, Otávio Gonçalves de Santana a écrit :
>
>
>
> (...snip...) I believe would be better remove this operations (multiply,
>
> divide, invert) both Unit and Quantity.
>
>
>
> I'm neutral about removing them from Quantity - I understand that some
>
> peoples may be uncomfortable with the lack of type safety, and I think that
>
> providing any operation in Quantity (including add and subtract) is of
>
> limited use because of the performance impact compared to working on the
>
> double type directly. However removing those operations from Unit is a
>
> different story, as it would considerably reduce the usefulness of this
>
> library.
>
>
>
>
>
> - *The main platform to JSR 363 is ME:* Beside we have plans to
>
> OpenJDK and Java SE platform, the main goal should be the ME, this way,
>
> we
>
> haven't features that help us such reflexion/proxy API.
>
>
>
> Note that the need for reflexion/proxy API should be only for Quantity,
>
> not for Unit.
>
>
>
> Martin
>
>
>
>
--
Otávio Gonçalves de Santana
blog:
http://otaviosantana.blogspot.com.br/
twitter:
http://twitter.com/otaviojava
site: *
http://about.me/otaviojava <
http://about.me/otaviojava>*
55 (11) 98255-3513