I'm also still not convinced.
Let's step back a few meters and simply compare the benefits vs the downsides
- PRO
* more 'modern'
* Optional
* Functions
* default methods in interfaces
- CON
* not backward compatible
* blocks adoption in current containers
* blocks adoption in many user projects
* we actually don't really need any of it's features
Let's face it: JDK8 is still not production ready. It is somewhat slower than
Java7 still and I honestly know no single big project which runs on Java8. Not
even the JavaEE7 TCK passes on Java8...
Ad Optional:
The discussion we had was around Optional. The only impact it has on me now is
that instead of
if (blabla != null) {...}
I've seen
if (blabla.isPresent()) {..}
Most code I've seen simply don't use the ?. chain notation because it only
works for 'navigation' use cases. Which we barely have (except for programmatic
default values, but there are perfectly valid alternative solutions as well).
Ad Functions:
I've not yet seen a benefit in our current API. Actually the only thing we use
it for currently is to replace 2 Comparator instances. I don't think this is
something we could't do with SE7 as well ;)
Ad default methods in interfaces:
Actually I'm not a huge fan of all those convenience functions in our
Configuration interface anyway. It just makes it harder to read.
What about adding either a branch or a module for java7?
That way we could continue trying implement our core functionality with both.
And at the end of the day we do a resume and weight up the pros and cons again.
LieGrue,
strub
> On Friday, 2 January 2015, 14:02, Werner Keil <[email protected]> wrote:
> > Romain,
>
> That's a good point. I flagged this with e.g. JavaMoney. Given it aims more
> at future platforms and e.g. java.util.Currency (or ICU4J) are already
> available for Java 7 or even 6 and before, that seemed of less concern to
> the EG or Anatole. Oracle stated, Lambdas may come to ME 8.x or 9, so a
> theoretical ME usage of the API could work in a future version of Java
> (ME), too.
>
> Here it's more about backward-compatibility, and looking at other Apache
> projects like DeviceMap, etc. a majority requires at most Java 6 as minimum
> version today. Some may have shifted to 7, but I couldn't think of an
> Apache project that was Java 8 minimum. CDI 2 plans to do that, so some
> modules in DeltaSpike could eventually graduate to CDI 2 and require Java
> SE 8, but a prior version of the same projects or modules will still work
> with CDI 1.x and Java 7.
>
> There are a few "functional" aspects, but if you need to declare a
> "Functional Interface" that works in Java 7 and 8 all you have to do
> is
> forget about the SE 8 annotation. It'll still work in 8 if declared right.
> So we might have to declare some of the interfaces without the
> @FunctionalInterface annotation (or comment it out for now) and refrain
> from reusing those Java SE 8 provides. Stubbing them out with either config
> specific or the same method names would be a solution.
>
> Optional was discussed in a hangout last night, and I wasn't under the
> impression we would have to use it in places where a simple "null
> check"
> also works, so that doesn't look like a Java SE 8 feature to be seen as
> mandadory or inevitable either.
>
> If the API was mostly portable, then some implementations or modules could
> be SE 8 Specific. I heard, that is somehow like Spring does it, too;-)
>
>
> Werner
>
>
> On Fri, Jan 2, 2015 at 12:03 PM, Romain Manni-Bucau
> <[email protected]>
> wrote:
>
>> Hi guys,
>>
>> I know we said java 8 is good to start a project but this is a blocker
>> to make of tamaya built in config solution in project bound to java 7
>> like JavaEE 7 containers for instance.
>>
>> Since Java 8 doesn't bring anything on implemtation point of view we
>> mandate/cant replace by java 7 can we rethink about it?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>
