Groovy bugs on JIRA

Cédric Champeau cedric.champeau at gmail.com
Fri Feb 7 06:01:35 PST 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140207/72d360bb/attachment.html 


More information about the mlvm-dev mailing list