Testing Groovy against JDK 8 EA builds

[Balchandra Vaidya]

Here is email reply from David Holmes.



-------- Original Message --------
Subject: 	Re: Testing Groovy against JDK 8 EA builds
Date: 	Wed, 20 Nov 2013 05:30:33 +1000
From: 	David Holmes <david.holmes at oracle.com>
Organization: 	Oracle Corporation
To: 	Balchandra Vaidya <balchandra.vaidya at oracle.com>
CC: 	quality-discuss at openjdk.java.net, hotspot-dev at openjdk.java.net



The VerifyError is VM related and there are still ongoing changes as the
spec settles and the implementation catches up.

The List issue is something to discuss on lambda-dev. We know there are
some source incompatabilities with default methods in Java 8. This is an
accepted price to pay for moving the Java libraries forward.

David

On 20/11/2013 2:35 AM, Balchandra Vaidya wrote:
>
> Hi Jochen,
>
> There could be multiple issues here and will require further
> information. I am copying hotspot-dev mailing list for further
> guidance.
>
>
> Thanks
> Balchandra
>
>
>
> On 11/19/13 03:29 PM, Jochen Theodorou wrote:
>>
>> Hi all,
>>
>> Dalibor and Rory suggested I comment on how well Groovy works with
>> jdk8-ea. I thought I write directly to the mailing list here to share
>> the problems.
>>
>> So I used 1.8.0-ea-b115 and run our test suite to give a short
>> overview. Of course we have to look into those issues in detail at
>> some point. Anyway, we get 31 (out of 6107) failing tests.
>>
>> All failures seem to be related to default methods.
>>
>> We have some helper methods we add to our classes and for example a
>> class extending LinkedList gets a helper method stream() and tries to
>> call it with invokeSpecial. The result is a VerifyError. The majority
>> of problems are like that. Of course that means tests involving these
>> classes have not been executed.
>>
>> We get also several null pointer exceptions, which seem to be related
>> to List#sort. We ourselves provide a sort(Comparable) method on
>> Iterable, but that method returns a List. The default method
>> List#sort(Comparable) is void and hides the Iterable one, thus the
>> method will return null and subsequent calls on the result fail with
>> NPEs.
>>
>> Those name clashes are a bit problem here I must say. Sure, we can
>> rename our method, but numerous examples out there use it. And worse,
>> our method is not mutating, the jdk one is. I am not yet sure what we
>> will do about that in general.
>>
>> bye Jochen
>>
>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20131120/0b3b8886/attachment.html