I've got an old project in Eclipse 2.1 and compiled with a JDK 1.4.2_12. I want to upgrade the version of Eclipse to Eclipse Galileo.
I've imported my project and set the compilation level to 1.4 and I've also updated my build path to use the correct JDK.
The problem is that when I compare the compiled files in the classes folder in the two versions of Eclipse, the MD5 checksum are different.
Should I be worried about that fact or this is normal?
This is normal. The Eclipse compiler is free to change the class file structure as long as it conforms to the 1.4 JVM specification. If a 1.4 JVM will load and run the class, I see no issue.
For truly pedantic cases, you should do your final builds with a JDK which matches the JRE, and not the Eclipse compiler.
As long as the program is working i dont think that you need to worry!!!
As MD5 would be unique for each entity, and it represents the Hash value.
It's normal, but I would make sure about doing a complete rebuild anyway (possibly erasing any existing class files). My experience with Eclipse is that the incremental builder doesn't react well to unexpected situations.
Related
I'm using java 1.8 with lots of pleasure.
One of my projects in my workspace needs to compile and be compatible with java 1.6, so i changed the appropriate eclipse options.
Now i get the famous message:
Build path specifies execution environment JavaSE-1.6. There are no JREs
installed in the workspace that are strictly compatible with this environment.
There are many questions and answers on how to solve this problem. So no problem there.
But what are theoretically the problems that may come up when this warning is ignored? (everything seem to be running nicely on 1.6)
One potential problem is that your 1.6-targeted code may accidentally use a class or interface that is introduced in JDK1.8. If the JRE that is associated with a 1.6 target in your workspace is actually a JRE1.8 or 1.7, the code may compile fine but you may end up with something like NoClassDefFoundError at runtime.
On our hadoop cluster my Pig UDF fails complaining
[main] ERROR org.apache.pig.tools.grunt.Grunt - ERROR 1069: Problem resolving class version numbers for class <classname>
I read writing a udf in pig kind of like tutorial and the problem seams to be clear, but unfortunately I cant solve it. My manifest does not contain a version (is this necessary?) and javap reports major version 52, representing java 1.8, although I compiled it with 1.7. So how can I solve this?
My manifest does not contain a version (is this necessary?)
The version manifest entry is not relevant to this. The classloader pays no attention to the version manifest entry.
and javap reports major version 52, representing java 1.8,
That is the relevant fact.
although I compiled it with 1.7.
This all boils down to how you compiled your code, and I think you are incorrect when you say that you compiled with Java 1.7.
Why do I say that? Because the Java 1.7 java compiler is not capable of creating a ".class" file with the Java 1.8 version numbers. It simply doesn't understand the Java 8 syntax extensions, and the corresponding enhancements to the classfile format.
So how can I solve this?
The way to resolve this is to look carefully at your build process and figure out how and why the offending class got compiled using a Java 1.8 compiler. Because there can be no doubt that that is what has happened.
If you are building by hand (e.g. by running "javac" and "jar" from the command line, or by clicking buttons in your IDE) then now would be a good time to learn about build tools like Maven, Ant and Gradle.
FOLLOWUP
That not true. My setting proofs this, but I guess I found the issue: .settings/org.eclipse.jdt.core.prefs contain several 1.8. entries. This may be due to the fact that at the time of the project creation I had 1.8. installed.
Actually, it doesn't "prove" anything ...
What this is telling me is that you are probably compiling with the Eclipse Java compiler, not the Java compiler from your JDK.
In fact, your Eclipse compiler is (or was) compiling for a Java 1.8 target ... because that is what your Eclipse settings say that the Eclipse Java compiler should do. If you are using the Eclipse compiler to compile your code, the version of your JDK or JRE install doesn't determine the classfile version number.
Once again, I strongly recommend that you learn to use a Maven, Ant or Gradle so that you build process is more repeatable and less error prone.
I guess Stephen C's is the most general answer.
In my special case the problem was, that the project specific compiler compliance settings were wrong, because I used JDK 1.8 locally when I created the project and installed 1.7 later, when I got the error on the cluster.
The option is quite hidden and can be found here:
Window > Preferences > Java > Compiler > "Configure project specific settings" > [projectname] > "Compiler compliance level"
I have a PowerMac and it is giving me bad version number on some .jars. I would love to make it seem like I am running Java 6. How would I spoof the version? Let me also say I am running PowerPC and Leopard
The most likely problem is that you have Java 6 JAR files and you are trying to run them on an old Java installation.
How would I spoof the version?
The answer to your question is that you can't. The way to run Java 6 specific JAR files it to use a Java 6 (or later) JRE or JDK.
The problem is that the format of Java class files has changed, and your installation can't cope with the new format. And this is not a gratuitous change that you can pretend doesn't exist. Java 6 (actually Java 5) has support for generic types, enums, annotations and other things. Assuming that the JARs contain code that uses these new language features, an older JRE simply won't know what to do with them.
There are two solutions:
Upgrade your Java installations to the required level on all machines. This is the best solution ... if it is an option ... because it means your users will get the benefit of security and bug fixes and performance enhancements. (And progress of your project won't be held back by the constraint of supporting legacy platforms.)
Compile all of your code for compatibility with the oldest version of Java that you still have to use. Either compile on the corresponding old JDK, or on a more recent JDK using appropriate -source / -target / -Xbootclasspath options ... as described by the javac manual page.
The catch with the second solution is that if the source code for the JAR files in question uses recently added Java language features or APIs, then recompiling for the older platform will fail. To fix this you will need to rewrite your code to replace the nice modern stuff with archaic stuff. Not a good solution, IMO.
The other possibility is that you are seeing corrupted JAR files. This is unlikely, but it can happen if you are using applets or webstart, and the server is delivering error pages instead of JAR files.
The third possibility is that you simply haven't configured your Mac's Java installation's correctly. Making Java 7 the default should allow you to run everything without class version problems. (Thanks #paulsm4) Note that I can't help you with that ... 'cos I don't use Java on a Mac.
I am from .net world. I remember .net will immediately complain if you build with one dll but supply a different dll at run time.
I am now adding some hadoop reference to my project and find the following article.
http://answers.mapr.com/questions/364/maven-repository-for-mapr-jar-files
I just don't understand how this happens.
Java can build with one jar but run with a different jar?
Thanks
yes. this is often the case with APIs (you compile the API, but at runtime you may run with a newer version of the API which may be included with the implementation). everything will work out fine as long as the classes/method prototypes referenced in your compiled code are unchanged from the jar you compiled against.
For a specific definition of compatibility, see binary compatibility (thanks to #MiserableVariable for the link).
I have a 3rd party JAR file that is compiled using Java 1.4. Is there a tool that can make the jar file compatible with Java 1.6? (Something like 'retrotranslator' but what does the reverse of it).
I tried decompiling the class files and re compile them in 1.6 but it fails.
Here is the issue:
My project uses 'rsadapter.jar' for was 5.1 and I had my project setup in Eclipse 2.0 + JDK 1.4 and it used to work fine. Now, I have migrated to Java 1.6 and Eclipse Ganymede (as per the requirements) and the same project (exactly same setup) started complaining about the missing class files in the 'rsadapter.jar'. I put the JAR in classpath explicitly too but it still could not load the classes. Then I changed the Java Compiler version to 1.4 and it started working.
Regards,
- Ashish
Classes compiled by JDK 1.4 should be usable in a Java 6 runtime as-is. If you have actually encountered a problem, please describe it.
Update: I can only reproduce this with types in the "default" package (that is, not in a package). Are the classes you are trying to use in the default package? Also, this happens to me regardless of the JDK version used to compile.
Update: Okay, after a little research, I realized that you can never reference a type in the unnamed package from a named package. Makes sense, but definitely not what you are running into.
I can compile code under JDK 1.4.2_19 and utilize it just fine in a Java 6 Eclipse project. I think that this problem is something specific to your environment. In this situation, I would backup Eclipse and recreate everything (JDK installation, workspace, projects) from scratch, to see if I could clear it up.
I had another issue with some legacy code written in Java 1.4.x: the authors loved enumerations and loved to name the corresponding variables 'enum'. They even used it for package names. And this prevents from compiling the code under Java 1.5 (or higher) quite successfully.
Changing that automatically is quite an issue.
May be you have defined Eclipse to throw compiler errors on use of deprecated methods or classes?