Strange covariant/generics downcasting issue with JDK8
Mark Derricutt
mark at talios.com
Mon Nov 4 14:23:16 PST 2013
Vicente,
Thanks for the follow up - I was meaning to chase this up myself.
I tried my existing project with the latest TIP builds of JDK8 and the problem still occurs, however using your updated test case I still can't reproduce it.
I suspect you've not actually tried to run the maven based project I provided ( understandable as that's quite heavy weight if you've not got an install ), so I've simplified my test case repo down to a Makefile and the fest.jar I've been using:
https://github.com/talios/jdk8-covariantfail/archive/master.zip
Under JDK7 this yields:
bash-4.2$ java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
bash-4.2$ make clean classes
rm -f *.class
javac -g -cp fest-assert-core-2.0M10.jar AppTest.java
Note: AppTest.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
whilst under OpenJDK8:
bash-4.2$ JAVA_HOME=/Users/amrk/Applications/j2sdk-image java -version
openjdk version "1.8.0-jdk8-b108"
OpenJDK Runtime Environment (build 1.8.0-jdk8-b108-20130923)
OpenJDK 64-Bit Server VM (build 25.0-b50, mixed mode)
bash-4.2$
bash-4.2$ JAVA_HOME=/Users/amrk/Applications/j2sdk-image make clean classes
rm -f *.class
javac -g -cp fest-assert-core-2.0M10.jar AppTest.java
AppTest.java:50: error: cannot find symbol
.hasSize(3);
^
symbol: method hasSize(int)
location: class AbstractAssert
Note: AppTest.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
make: *** [AppTest.class] Error 1
Hopefully, with this simplified build you might be able to spot something more usefull?
Cheers,
Mark
On 2 Nov 2013, at 7:29, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Mark,
>
> I have been trying to reproduce the issue you reported. I have created a test case that should reproduce the compilation error but I couldn't. Please see my last comment in [1].
>
> I have compiled this test with last version of the compiler from [2], I get warnings but no errors.
>
> Maybe you can try to compile the test at [1] with your settings and confirm that you get the same error(s) as before. If you don't get the same errors could you please check that the test matches the version of fest-assert you are using?
>
> I have simplified the hierarchy while keeping the same method definitions, but I have seen that there are several versions of the library around so probably there can possibly be some**mismatches with your current version.
>
> Thanks,
> Vicente
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8026329
> [2] http://hg.openjdk.java.net/jdk8/tl/langtools/
>
> On 05/10/13 22:15, Mark Derricutt wrote:
>> Just following up on this now that Java One is over and hopefully more eyes can help me track down just what's going on here.
>>
>> Try as a may I've not yet been able to distil this problem down to a single class file to reproduce, but the extracted project on github ( https://github.com/talios/jdk8-covariantfail ) continues to fail under JDK8.
>>
>> The FEST-Assert library uses a fairly complex class hierarchy, employing some gnarly "self type" generics in order to provide the appropriate type to javac.
>>
>> When compiling under Java 7 the project works fine, but when compiling under JDK8 ( developer preview, and also HEAD/master builds from mercurial ) fail to compile the 2nd test function, as the inferred return type is getting lost somewhere along the way.
>>
>> If the 2nd test is broken up with intermediate variables then the call to hasSize(3) on line 37 compiles fine.
>>
>> Given this works under Java 7, and fails under Java 8 - this is clearly some form of regression/bug somewhere,
>> just exactly what is broken, and how to reproduce it is so far eluding me, any help in isolating this issue so that a relevant bug can be raised, tracked, and fixed would be helpful.
>>
>> Mark
>>
>>
>> --
>> Mark Derricutt <mailto:mark at talios.com> — twitter <https://twitter.com/talios> — podcast <http://www.illegalargument.com> — blog <http://www.theoryinpractice.net> — google+ <http://gplus.to/talios>
>>
>> On 23/09/2013, at 5:30 PM, Mark Derricutt <mark at talios.com <mailto:mark at talios.com>> wrote:
>>
>>> Hi all,
>>>
>>> Since you're all enjoying JavaOne at the moment I was thinking it was about time that I starting building $work's project under JDK8 and give it some love over my normal small projects and ran into an odd issue with generics/covariant returns that works fine under 7u40 and breaks under 8DP.
>>>
>>> I've extracted this into a simple project [1] which I've pushed to github, I've added a comment on the code that breaks under JDK8.
>>>
>>> The code in question is:
>>>
>>> List<Strings> strings…
>>>
>>> assertThat(strings).describedAs("test")
>>> .isNotEmpty()
>>> .has(regexMatch("th.*"))
>>> .doesNotHave(regexMatch("moo.*"))
>>> .hasSize(3);
>>>
>>> When calling assertThat(strings) a class of type ListAssertion is returned, and passed along the call chain.
>>>
>>> The problem appears to be that when doesNotHave() returns, javac no longer sees a ListAssertion but rather a top level AbstractAssertion on which doesNotHave is defined:
>>>
>>> /** {@inheritDoc} */
>>> public S has(Condition<? super A> condition) {
>>> conditions.assertHas(info, actual, condition);
>>> return myself;
>>> }
>>>
>>> /** {@inheritDoc} */
>>> public S doesNotHave(Condition<? super A> condition) {
>>> conditions.assertDoesNotHave(info, actual, condition);
>>> return myself;
>>> }
>>>
>>> Now, both has() and doesNotHave() appear to have the exact same signature, yet commenting out the call to doesNotHave() doesn't appear to trigger what appears to be a down casting to AbstractAssertion which doesn't include a method called hasSize(), the output I see from javac is:
>>>
>>> ~/D/covariantfail (master|…) $ /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -version
>>> java version "1.8.0-ea"
>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b106)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b48, mixed mode)
>>>
>>> ~/D/covariantfail (master|…) $ /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac -version
>>> javac 1.8.0-ea
>>>
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/javac -d /Users/amrk/Dropbox/covariantfail/target/test-classes -classpath /Users/amrk/Dropbox/covariantfail/target/test-classes:/Users/amrk/Dropbox/covariantfail/target/classes:/Users/amrk/.m2/repository/org/testng/testng/6.8.5/testng-6.8.5.jar:/Users/amrk/.m2/repository/junit/junit/4.10/junit-4.10.jar:/Users/amrk/.m2/repository/org/hamcrest/hamcrest-core/1.1/hamcrest-core-1.1.jar:/Users/amrk/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar:/Users/amrk/.m2/repository/com/beust/jcommander/1.27/jcommander-1.27.jar:/Users/amrk/.m2/repository/org/yaml/snakeyaml/1.6/snakeyaml-1.6.jar:/Users/amrk/.m2/repository/org/easytesting/fest-assert-core/2.0M10/fest-assert-core-2.0M10.jar:/Users/amrk/.m2/repository/org/easytesting/fest-util/1.2.5/fest-util-1.2.5.jar: -sourcepath /Users/amrk/Dropbox/covariantfail/src/test/java: /Users/amrk/Dropbox/covariantfail/src/test/java/com/talios/RegexMatch.java /Users/amrk/Dropbox/covariantfail/src/test/java/com/talios/AppTest.java -g -nowarn -target 1.5 -source 1.5 -encoding UTF-8
>>> /Users/amrk/Dropbox/covariantfail/src/test/java/com/talios/AppTest.java:37: error: cannot find symbol
>>> .hasSize(3);
>>> ^
>>> symbol: method hasSize(int)
>>> location: class AbstractAssert
>>> Note: /Users/amrk/Dropbox/covariantfail/src/test/java/com/talios/AppTest.java uses unchecked or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> 1 error
>>>
>>>
>>> Is this a known bug in the JDK at all? I'm quite surprised no one else has hit something like this before if its not?
>>>
>>>
>>>
>>>
>>> [1] https://github.com/talios/jdk8-covariantfail
>>> [2] https://github.com/talios/jdk8-covariantfail/commit/faa016e57f754230da46e3453b964d497ec065b5#commitcomment-4151896
>>>
>>>
>>>
>>> -- Mark Derricutt ( mark at talios.com <mailto:mark at talios.com> )
>>> — twitter: https://twitter.com/talios
>>> — podcast: http://www.illegalargument.com <http://www.illegalargument.com/>
>>> — blog: http://www.theoryinpractice.net <http://www.theoryinpractice.net/>
>>> — google+: http://gplus.to/talios
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20131105/40b2e162/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20131105/40b2e162/signature-0001.asc
More information about the compiler-dev
mailing list