Java 8 compiler bug?

Oliver Gierke ogierke at pivotal.io
Wed Nov 16 00:32:30 UTC 2016


I wasn't sure whether any specialty of the types involved is causing the issue, that's why I kept the JPA dependency in the first place. But this piece of code shows the same characteristics:

public class Ambiguity {

	public void foo(CriteriaBuilder builder) {

		Expression<Object> objectExpression = null;
		Expression<Collection<Object>> collectionOfObjectExpression = null;
		builder.isNotMember(objectExpression, collectionOfObjectExpression);
	}

	interface Expression<T> {}

	interface CriteriaBuilder {

		<E, C extends Collection<E>> void isNotMember(E elem, Expression<C> collection);

		<E, C extends Collection<E>> void isNotMember(Expression<E> elem, Expression<C> collection);
	}
}

> Am 16.11.2016 um 00:54 schrieb Jonathan Gibbons <jonathan.gibbons at oracle.com>:
> 
> Can you simplify your example down to something that doesn't require us to download a zip file?
> 
> -- Jon
> 
> On 11/15/2016 03:49 PM, Oliver Gierke wrote:
>> Sorry, I forgot the link to the reproducing example:
>> 
>> https://dl.dropboxusercontent.com/u/25310722/compiler-ambiguity.zip
>> 
>>> Anfang der weitergeleiteten Nachricht:
>>> 
>>> Von: Oliver Gierke <ogierke at pivotal.io>
>>> Betreff: Java 8 compiler bug?
>>> Datum: 16. November 2016 um 00:46:02 MEZ
>>> An: compiler-dev at openjdk.java.net
>>> 
>>> Hi all,
>>> 
>>> I just ran in this code compiling fine with a JDK 8 if I define a compilation source and target of 1.6, but not if I define both values of 1.8.
>>> 
>>> public class Ambiguity {
>>> 
>>> 	public void foo(CriteriaBuilder builder) {
>>> 
>>> 		Expression<Object> objectExpression = null;
>>> 		Expression<Collection<Object>> collectionOfObjectExpression = null;
>>> 		builder.isNotMember(objectExpression, collectionOfObjectExpression);
>>> 		//      ^^^^^^^^^^^ - ambiguous
>>> 	}
>>> }
>>> 
>>> CriteriaBuilder and all other types come from JPA. The method in question has two overloads:
>>> 
>>> <E, C extends Collection<E>> Predicate isNotMember(Expression<E> elem, Expression<C> collection);
>>> <E, C extends Collection<E>> Predicate isNotMember(E elem, Expression<C> collection);
>>> 
>>> I fail to understand why the second method is even considered as that create a contradiction between the bound values of E (Expression<…>) and C (Collection<Object>).
>>> 
>>> I've prepared an example here [0]. Steps to reproduce:
>>> 
>>> 1. Unzip
>>> 2. Run mvn clean compile -> fails
>>> 3. Change java.version property in pom.xml to 1.6
>>> 4. Run mvn clean compile -> succeeds
>>> 
>>> $ java -version
>>> java version "1.8.0_112"
>>> Java(TM) SE Runtime Environment (build 1.8.0_112-b16)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16, mixed mode)
>>> 
>>> Is that a known issue, something I oversee or should I create a ticket for that?
>>> 
>>> Cheers,
>>> Ollie
>>> 
>> --
>> /**
>>  * @author Oliver Gierke - Senior Software Engineer
>>  *
>>  * @param email ogierke at pivotal.io
>>  * @param phone +49-151-50465477
>>  * @param fax   +49-351-418898439
>>  * @param skype einsdreizehn
>>  * @see http://www.olivergierke.de
>>  */
>> 
> 

--
/**
 * @author Oliver Gierke - Senior Software Engineer
 *
 * @param email ogierke at pivotal.io
 * @param phone +49-151-50465477
 * @param fax   +49-351-418898439
 * @param skype einsdreizehn
 * @see http://www.olivergierke.de
 */

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161116/551cf860/signature.asc>


More information about the compiler-dev mailing list