[jira] [Commented] (GROOVY-8076) A more helpful error message should be logged when a custom Java class cannot be resolved by the Groovy component due to a Java major/minor version mismatch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[jira] [Commented] (GROOVY-8076) A more helpful error message should be logged when a custom Java class cannot be resolved by the Groovy component due to a Java major/minor version mismatch

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/GROOVY-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15929671#comment-15929671 ]

Paul King commented on GROOVY-8076:
-----------------------------------

I compiled this class under Java 8 but with 1.7 targetCompatibility:
{code}
//@Grab('io.javaslang:javaslang:2.1.0-alpha')
import javaslang.Tuple2
import javaslang.Tuple

class Jdk7Dep {
    def method() {
        Tuple2<String, Integer> java8 = Tuple.of("Java", 8)
        return java8
    }
}
{code}
and then tried to run this class under JDK7:
{code}
class Jdk7Main {
    static void main(String[] args) {
        Jdk7Dep temp = new Jdk7Dep()
        println temp.method()
    }
}
{code}
When trying to run I get this:
{noformat}
Exception in thread "main" java.lang.UnsupportedClassVersionError: javaslang/Tuple : Unsupported major.minor version 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        [...]
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at Jdk7Dep.method(Jdk7Dep.groovy:7)
        at Jdk7Dep$method.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
        at Jdk7Main.main(Jdk7Main.groovy:4)
:run FAILED
{noformat}
This seems okay to me.

> A more helpful error message should be logged when a custom Java class cannot be resolved by the Groovy component due to a Java major/minor version mismatch
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-8076
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8076
>             Project: Groovy
>          Issue Type: Bug
>          Components: groovy-runtime
>            Reporter: ANDREY GRIGORYEV
>
> I spent a couple of hours investigating why my application would no longer successfully deploy to the mule standalone ESB server, yet it would deploy fine to the embedded mule ESB runtime in Anypoint Studio. The error message that I found in the server log was something along the lines of the following:
> "... Script1.groovy: 1: unable to resolve class com.mycompany.MyReallyUsefulCustomClass ..."
> I went down all the wrong avenues trying to figure out why the Java class was not being resolved by the Groovy interpreter.
> Eventually I stumbled upon an explanation of the problem via a Google search: a Java major/minor version mismatch between the version of the Java runtime being used by the Mule ESB runtime and the Java target version of the compiled custom Java classes used by a Mule application being deployed to the Mule ESB server.
> The cause of my problem was indeed due to a Java version mismatch: the ESB server runtime was running JRE 1.7, but the custom class being referenced by the embedded Groovy script was compiled in Anypoint Studio using JDK 1.8.
> I would like to formally submit an Enhancement Request for Engineering to improve the customer experience for us developers; possibly by updating the Groovy interpreter component to detect the conflicting Java version issues and log a more helpful error message to the logger.
> The current message "... unable to resolve class ..." is too general and does not adequately reflect the problem of a mismatch between the JRE version and the compiled byte-code version.
> An "Unsupported major.minor version x.yy" error message instead would be an improvement.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
Loading...