Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Werner Keil <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Sun, 19 Oct 2014 17:09:22 +0200
It however looks like especially the Output of Unit<?> is going to cause us
trouble in JDK8+ ;-/
Remember the ReflectionDemo?
Either Eclipse (JBoss Tools) does not provide full Java 8 support in cases
(some of the LJC circulated issues also mentioned differences among IDEs)
or me rolling back the Unit.mulitply() change to its old wildcard output...
The reflect() method of ReflectionDemo won't compile with Unit<?> either
for input parameters coming from at least a "chain" of wildcards like
Unit.multiply(Unit<?>).asType() which again throws out Unit<?>.
As mentioned, JDK updates would help us little, full reified types could
sime day allow easier access to the Quantity subtype, but we need to
OpenJDK team about short term changes that would affect implementations or
make them incompatible. Value types could benefit from this JSR, too but
may have less impact on the API at first.
We'll have a Hackergarten with MoroccoJUG at JMaghreb. Given Guilaume's
great support of JSR 275 in Groovy, having Andres run it could allow a
"Reality Check" for JSR 363 and its RI (Groovy does not require SE8 for
now) to see, how well they work to create a similar DSL in Groovy or Scala.
Including methods, I suppose what works for BigDecimal or JSR 354 also did
here;-)
Werner
Am 19.10.2014 16:22 schrieb "Martin Desruisseaux" <
>:
>
Le 19/10/14 04:20, Otávio Gonçalves de Santana a écrit :
>
> Martin, maybe I expressed me bad.
>
> Java has the Generic resources in Java 1.5, but it should to keep the
>
> compatibility to older version of Java.
>
> When I told "new API", I means API after the generics, in other words,
>
> Java 1.6 or above.
>
> If you look to the Since annotations of this example you will see
>
> almost always 1.4 and Just one 1.5 , in other words, no one is new API.
>
>
I do not think that it matter much. The JDK team had the freedom to add
>
whatever parameterized type they wanted in the API - this was the
>
purpose of "type erasure". They were not forced to use <?> for
>
preserving compatibility. Indeed, they used massively more complex types
>
in large part of the API: collections (which is a Java 1.2 API),
>
reflection, swing, etc. Consequently I think that their use of
>
Comparable<?> was a design choice, not a compatibility constraint.
>
>
<?> is not necessarily "old school", "legacy" or "bad design". In some
>
situations it is really the most appropriate signature.
>
>
Martin
>
>