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 <anis...@redhat.com> 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 <gal...@redhat.com> 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 >>>> gal...@redhat.com >>>> twitter.com/galderz >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> -- >>> Galder Zamarreño >>> gal...@redhat.com >>> twitter.com/galderz >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
