[infinispan-dev] Infinispan Test language level to Java 8?

Wed Apr 30 12:54:07 EDT 2014

On 30 April 2014 17:41, Adrian Nistor <anistor at redhat.com> wrote:
> 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.

I'm assuming we would not jump to rewrite all existing tests, and that
we would be running most tests on CI using Java7.

If I misunderstood, then yes I agree with you and would be against the
proposal. As mentioned below, I don't want to rely on animal-sniffer
for this.

Sanne

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