Alright, so after building the latest (jdk7u this time) JDK sources... I
have coherent (but failing) results. Both 7u60b04 [1] and latest jdk7
sources [2] fail, with similar errors:
target and fallback types must match:
(Object,Object,Object,Object,Object,Object,Object,Object,Object)Object !=
(Class,SourceUnit,Object,Object,Object,Object,Expression,Object,Object)Object
This means that [3] can be closed, but not [4].
Best regards,
(login: guest, no password)
[1]
http://ci.groovy-lang.org/viewLog.html?buildTypeId=Groovy_Jdk7snapshotBuild&buildId=878
[2]
http://ci.groovy-lang.org/viewLog.html?buildTypeId=Groovy_Jdk7snapshotBuild&buildId=877
[3] https://bugs.openjdk.java.net/browse/JDK-8033671
[4] https://bugs.openjdk.java.net/browse/JDK-8033669
Le 07/02/2014 09:49, Cédric Champeau a écrit :
Hi all,
I am the reporter of both bugs on JIRA, on behalf of the Groovy team.
I would definitely like to comment on the JIRA issues and give more
insight here, unfortunately this is impossible and it makes
communication really painful. I created those bug reports after Rory
asked me to. So I feel like repeating myself too many times. Now that
I bragged about it, let's get to the point :)
So the context. We have a CI server which tests multiple JDK
configurations. All configurations can be seen in [1], the server is
public, you have access to all build log files as well as exception
stack traces (just use "guest" to login and no password).
The "JDK 7" build is using *JDK 1.7u11*, which is the latest JDK7
version to successfully pass all tests of Groovy.
The "JDK 7 snapshot" build is using a JDK*built from sources.* It is
using the *latest sources*, and it corresponds to the bug report [2].
So when you see "b17", it doesn't mean it corresponds to *your* b17,
it's just that JDK7 uses an environment variable to set the build
version, while JDK8 does *not* (uses -internal instead).
The "JDK 8 snapshot" build is using a JDK *built from sources* too.
This version passes all tests of Groovy.
We also run specific builds when you release EAP versions of the JDK.
This one [4] is for example on JDK7u60b04. So my first bug report[3]
corresponds to a crash test on JDK7u60b04, that is to say the latest
published JDK7 version. This is really different from my second bug
report [2] which corresponds to the latest state of JDK7 sources.
So to sum up:
* no version of JDK7u60, be it 7u60b04 or latest sources, allows
us to build Groovy. The errors are indeed different in both versions,
hence different bug reports, but reproducible, as I encourage you to
take a look at the stack traces on the CI server.
* JDK8, including the RC, passes the build successfully.
* JDK7u11 is the *latest* known version of JDK which successfully
passes the Groovy build *and* doesn't have any annoying bug (like the
infinite loop in classloader)
It would really be a pity if u60 goes out and that we still don't have
a JDK7 version which successfully completes the Groovy build. The fact
that we don't have the same errors on 7u60b04 and snapshot jdk is
puzzling and makes things even more complicated. I just hope those
explanations make things clearer.
[1] http://ci.groovy-lang.org/
[2] https://bugs.openjdk.java.net/browse/JDK-8033671
[3] https://bugs.openjdk.java.net/browse/JDK-8033669
[4]
http://ci.groovy-lang.org/viewLog.html?buildId=410&tab=buildResultsDiv&buildTypeId=Groovy_Jdk7snapshotBuild
Best regards,
--
Cédric Champeau
SpringSource - Pivotal
http://spring.io/
http://www.gopivotal.com/
http://twitter.com/CedricChampeau
--
Cédric Champeau
SpringSource - Pivotal
http://spring.io/
http://www.gopivotal.com/
http://twitter.com/CedricChampeau
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
