Hi all, Just thinking out loud: what about we start using JDK8+ for all the test code in Infinispan? The production code would still have language level 6/7 (whatever is required…). This way we start getting ourselves familiar with JDK8 in a safe environment and we reduce some of the boiler plate code currently existing in the tests. This would only problematic for anyone consuming our test jars. They’d need move up to JDK8+ along with us.

Thoughts? p.s. Recently I found https://leanpub.com/whatsnewinjava8/read which provides a great overview on what’s new in JDK8 along with small code samples. -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

> Another potential problem, as rightly pointed out by Will on IRC, is that it would also cause issues for anyone trying to run our testsuite with JDK7 or earlier, if anyone is doing such a thing. Galder, we may be doing such a thing :) The test suite is meant to verify correctness of our libraries when executed against a concrete set of external dependencies, with clearly specified supported versions or version intervals - the jdk being the most important of them. Since we'll no longer be able to run on jdk 7 we can no longer support jdk. Even if animal-sniffer cheerfully reports we've not broken binary compat, that still does not mean much when it comes to jdk version specific issues, or jdk maker specific issue (remember the IBM jdk oddities). Mavenwise, I think it is not possible to have a different compiler language level for module sources vs. test sources and Eclipse and Intellij also cannot cope with two source levels per module, so this would introduce some unnecessary development discomfort. I would vote no for this. Adrian On 04/30/2014 02:55 PM, Galder Zamarreño wrote: > On 30 Apr 2014, at 13:36, Galder Zamarreño <galder(a)redhat.com&gt; wrote: > >> Hi all, >> >> Just thinking out loud: what about we start using JDK8+ for all the test code in Infinispan? >> >> The production code would still have language level 6/7 (whatever is required…). >> >> This way we start getting ourselves familiar with JDK8 in a safe environment and we reduce some of the boiler plate code currently existing in the tests. >> >> This would only problematic for anyone consuming our test jars. They’d need move up to JDK8+ along with us. > Another potential problem, as rightly pointed out by Will on IRC, is that it would also cause issues for anyone trying to run our testsuite with JDK7 or earlier, if anyone is doing such a thing. > >> Thoughts? >> >> p.s. Recently I found https://leanpub.com/whatsnewinjava8/read which provides a great overview on what’s new in JDK8 along with small code samples. >> -- >> Galder Zamarreño >> galder(a)redhat.com >> twitter.com/galderz >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > galder(a)redhat.com > twitter.com/galderz > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I don't see those concerns as lightly as you put them. Animal-sniffer is just a quick fail-fast check for binary compatibility of type hierarchy and method signatures, but that's not everything. The only sure way to test against a particular jdk version is to actually run the test suite with it. Seeing is believing. That's why we have separate CI jobs running against older supported jdks. I fail to see how this works when our unit tests are written using jdk 8 features.

On 04/30/2014 05:31 PM, Sanne Grinovero wrote: > Valid concerns, but I think we should split those in two very > different categories: > 1- we provide testing utilities which are quite useful to other people too > 2- we run unit tests on our own code to prevent regressions > > If we split the utilities into a properly delivered package - built > with Java7, having a very own Maven identity and maybe even a user > guide - that would be even more useful to consumers. For example I use > some of the utilities in both Hibernate Search and Hibernate OGM, > dependending on the testing classifier of infinispan-core. I'd prefer > to depend on a "proper" module with a somehow stable API, and this > would be a great improvement for our users who start playing with > Infinispan.. I often refer to our testsuite to explain how to setup > things. > > For the second use case - our own test execution - I see great > advantages from using Java8. First of, to verify that the API's we're > developing today will make sense in a lambda enabled world: we might > not baseline on it today but it's very hard to do forward-compatible > thinking without actually experimenting with the API in TDD before > this is cast in stone. Remember TDD is a design metodology, not a QA > approach. > > But I agree with Adrian on not wanting to fully trust animal-sniffer > with this task, nor I like the "flexibility" we have in IDEs for a > single module being mixed. > For the record Hibernate has been since long keeping the test > infrastructure in a different module; we could explore an alternative > code organization. While it's important to have some core tests > closely coupled with the module it's meant to test, I don't see why we > couldn't have additional tests in a different module? > > +1 to have at least one module using (requiring) Java8. Yes, > contributors will need to have it around.. I don't see a problem, any > potentially good contributor should have it around by now. > > Sanne > > > > On 30 April 2014 13:12, Adrian Nistor <anistor(a)redhat.com&gt; wrote: >> > Another potential problem, as rightly pointed out by Will on IRC, is >> that it would also cause issues for anyone trying to run our testsuite >> with JDK7 or earlier, if anyone is doing such a thing. >> >> Galder, we may be doing such a thing :) The test suite is meant to >> verify correctness of our libraries when executed against a concrete set >> of external dependencies, with clearly specified supported versions or >> version intervals - the jdk being the most important of them. >> >> Since we'll no longer be able to run on jdk 7 we can no longer support >> jdk. Even if animal-sniffer cheerfully reports we've not broken binary >> compat, that still does not mean much when it comes to jdk version >> specific issues, or jdk maker specific issue (remember the IBM jdk >> oddities). >> >> Mavenwise, I think it is not possible to have a different compiler >> language level for module sources vs. test sources and Eclipse and >> Intellij also cannot cope with two source levels per module, so this >> would introduce some unnecessary development discomfort. I would vote >> no for this. >> >> Adrian >> >> On 04/30/2014 02:55 PM, Galder Zamarreño wrote: >>> On 30 Apr 2014, at 13:36, Galder Zamarreño <galder(a)redhat.com&gt; wrote: >>> >>>> Hi all, >>>> >>>> Just thinking out loud: what about we start using JDK8+ for all the test code in Infinispan? >>>> >>>> The production code would still have language level 6/7 (whatever is required…). >>>> >>>> This way we start getting ourselves familiar with JDK8 in a safe environment and we reduce some of the boiler plate code currently existing in the tests. >>>> >>>> This would only problematic for anyone consuming our test jars. They’d need move up to JDK8+ along with us. >>> Another potential problem, as rightly pointed out by Will on IRC, is that it would also cause issues for anyone trying to run our testsuite with JDK7 or earlier, if anyone is doing such a thing. >>> >>>> Thoughts? >>>> >>>> p.s. Recently I found https://leanpub.com/whatsnewinjava8/read which provides a great overview on what’s new in JDK8 along with small code samples. >>>> -- >>>> Galder Zamarreño >>>> galder(a)redhat.com >>>> twitter.com/galderz >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> -- >>> Galder Zamarreño >>> galder(a)redhat.com >>> twitter.com/galderz >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Hi all, Just thinking out loud: what about we start using JDK8+ for all the test code in Infinispan? The production code would still have language level 6/7 (whatever is required…). This way we start getting ourselves familiar with JDK8 in a safe environment and we reduce some of the boiler plate code currently existing in the tests. This would only problematic for anyone consuming our test jars. They’d need move up to JDK8+ along with us. Thoughts? p.s. Recently I found https://leanpub.com/whatsnewinjava8/read which provides a great overview on what’s new in JDK8 along with small code samples. -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev