I am moving from Groovy 1.76 to groovy 2.1 and am having a problem running some Java code.
I have java 7 and Groovy 2.1 all setup on my classpath. Gradle is running and my project can run all its unit tests and execute successfully just as before.
However, I have one java class that loads up one of the groovy classes and executes it (the class can be executed normally in regular gradle/groovy unit tests) and when I try to run this in the new environment it fails with the following exception:
Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/groovy/transform/powerassert/ValueRecorder
at com.covestor.glossary.meta.Entity$_Rel__clinit__closure3_closure4.doCall(Entity.groovy:500)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
I have seen in other questions/discussions that some classes were removed from Groovy 1.7, so the general advice seems to be to make sure the classes are re-built against a later version of groovy - but my classes are already being built against the later version (my script that kicks off the java code actually calls gradle clean build first to make sure all groovy classes are properly compiled). There are some jar dependencies as well, but none of them are built from Groovy source (all java jars).
Can anyone suggest what the problem might be? I can't see that I have any code anywhere that is still built against 1.7
The ValueRecorder class is used internally to implement the power assert feature in Groovy. Unfortunately, these classes have been moved to another package from 1.7 to 1.8.
Your error means there is still some 1.7 compiled Groovy code. That's the reason for the NoClassDefFoundError.
I had a similar issue when upgrading, I never created a new GROOVY_HOME to point to the new version of groovy...did you do that and also add $GROOVY_HOME/bin to your path?
Related
I have java EE artifacts like .jar , .war, .ear files compiled and running in java 1.6 version. i wanted to run them (.ear file [.jar + .war]) in latest java versions like java 1.8.
Which Option would be the best considering moving to new java version.
1) Recompile Code in 1.8 and deploy to Application server
- to be at a little safer.
2) Just deploy to java 1.8
- No Code Compilation required (means .ear file generated using java 1.6). .ear file can be safely deployed to latest java 1.8 version
- probably we wont end-up having runtime issues ?
As this this is a production code base and no developer. Hence No Code changes in either cases, the only change is java version. I prefer going with Option-1, as compilation in higher version of exiting java classes to avoid any runtime issues.
Any thoughts ! or other useful options in this regard.
Thanks
As #Stultuske mentioned you only telling no code changes possible in either cases then your first case not valid one only.
But anyway as per java(Oracle) compatibility specification Java 8 is backward compatible with previous versions for sure no doubt about this except some very rare cases where binary incompatibilities happened.
For more information about this you can refer below stack overflow link --
Can newer JRE versions run Java programs compiled with older JDK versions?
Recently I did a similar thing but we updated the code/dependencies if needed.
I will suggest recompiling the code base first because this will tell you quickly if it or any dependencies don't support the newer Java version. If compilation is successful, then deploy to test environment and do sanity, regression, etc.
I hope you aren't talking about deploying to Production environment directly :)
I'm facing a very silly problem.
If I build my project using the Eclipse UI, it builds and runs fine. However, if I build it on the command-line using the plain old javac (i.e., without any ant or maven build tool), I get a code too large error on one of the files (which, btw, happens to be a Antlr3-generated Java parser file).
What's strange is:
My Eclipse project is pointing to the same JDK that I'm using on the command-line! So, it is not the case that I'm inadvertently using built-in Eclipse Java compiler
If the parser code were really 'too large' (some method in it being > 64K), why isn't the Eclipse build resulting in the same error? For this very reason, I'm also reluctant to start tweaking my parser grammar - a much more involved task.
I'm using Eclipse Neon and Oracle JDK 1.8.
The Eclipse UI always uses the Eclipse Java compiler, it never uses javac. So it may be the Eclipse compiler is doing a better job in this case.
The installed JRE is used for the libraries and the JVM when you are testing. Eclipse always uses its own compiler since it needs to do incremental compilation which javac can't do.
I am running into an issue with my gradle build script, build.gradle, for my java project. In this script I need to compile the application with Java 6 in order to comply with the application specifications. However, I am also using a gradle plugin that performs code analysis that needs to be run under a Java 8 JVM. What do I need to do in build.gradle or other gradle settings in order to get this plugin to use a separate Java JVM?
I need to do something like this as gradle tasks fail because the plugin is reporting a Unsupported major.minor version 52.0 Error.
Research
I have done some invesitigation and I did see the following mentioned:
options.fork = true
options.forkOptions.executable = System.getenv('OTHER_JAVA')
Where OTHER_JAVA is an environment variable to the other version of Java. However, I have not been able to get this to work for the plug-in and after some more research, it looks like this may be more limited to compiling with a separate version of java, not executing.
See: How do I tell Gradle to use specific JDK version?
You've pretty much answered your question yourself:
it looks like this may be more limited to compiling with a separate version of java, not executing
Run Gradle under the Java 8 (that would mean specifying your JAVA_HOME as JDK 8), and fork the compiler for your app with Java 6 (as per your research).
When creating a launch configuration you can specify an Execution environment, how is that more specifically used? I assume it ends up as a parameter to Java?
What are the consequences if we have a plugin built with JavaSE-1.8 execution environment, and run an application using that plugin and run it with execution environment JRE-1.1?
Explanation:
It won't run. Execution environment says the code is intended to be executed in a certain Java implementation. This affects both: the bytecode version your sources get compiled into and Java Class Library you're code is intended to use. The setting is used by IDE (not sure all IDEs use it - Eclipse does) to make sure you only write code possible to execute in a give EE.
Bytecode incompatibility example:
Java 8 added lambda support - if you use it your bytecode will have labmda related instructions and it will not execute in older JVMs.
JCL incompatibility example:
Java 8 introduced URLPermission class. If you refer to it in your code and try to run it against older Java Class Library you'll get an exception. Even if you compile your code into older bytecode version. The class is simply not accessible in older JCL.
Links:
Eclipse community has a lot of resources on Java Execution Environments - read about it here.
1.8 to 1.1? so much of discord in versions? Anyways, launch configuration has data about path of jre, depenedency jars and location of files where parameters needed by program are stored.
if you change env, your code may not be source compatible or you may get errors like 'file not found /class not found'.
I have a java program consists of a jar for the "real program" and a sub-folder containing 20 jar library files (also have dependencies between them). I tried but without success ... I'm missing with the many options that gcj to compile :(. Does anyone know how to compile to native code so that a java program?
Thanks
Update: I have used the plugin for Eclipse (I'm using the 3.6 version of Eclipse and the plugin works well) http://gcjbuilder.sourceforge.net/ to generate a Makefile for the compilation. But now I have an another problem :(
Some libraries are not compiled (exit for error). The error is that GCJ considers all .class files inside .jar file, that have dependencies with other libraries do not exist. But for the purposes of my program, these classes are not used (that is, the java program it works properly). There is thus a way to force gcj to consider only the classes actually used in my java program?
I can only recommend that you don't use GCJ. It isn't Java. The compatiblity matrix on their web page is far from encouraging. It doesn't implement Java 1.2 completely yet, let alone all of 1.3, 1.4, 1.5, 1.6. The project appears to be falling further and further behind, and it never had 100% Java compatibility as a stated goal in the first place.
You may want to look at tools like autojar and firends to help resolve your dependencies and to make a single jar.