I'm trying to run an application with java 1.7.2 and its complaining it needs java 1.6 and up.
Is there a way to bypass that check(without recompiling, I don't have the source code)? both for casual use and so I can say that it seems to work in the bug report?
You need to decompile the bytecode to see how the code checks the java version. Maybe the bytecode tries to check a system attribute? In that case, you can reset the attribute to '1.6' before starting the proprietary code.
I can recommend DJ as a decompiling tool.
It is better to decompile the version checking code, to correct it and to recompile it. This will be hard if the code was obfuscated however.
Related
My requirement is, I have a third party jar file and I am using Java 1.6 now. But due to version upgrade/migration the application needs to be moved to JAVA 1.8. I need a tool/utility/standalone program that will inspect my class/jar file and will give a summary/report which will tell whether there is any compliance issue.
For ex - Method deprecation. Thread.stop() is deprecated. The existing code will not run in higher version and will throw exception.
The best tool for doing this ist the java compiler. It can tell you what will not work anymore (errors) and which classes/methods are deprecated.
I try to write my code compatible with older versions of java, so it will work everywhere.
on the other hand there is very powerful tools in the new version - java 8, and I want use them.
So I'm forced to choose between compatibility or richest code.
And I'm wondering if by any chance I can write some methods in java 8, and somehow prevent the compiler of older version to ignore these methods, so my class is compatible "partially" with older version.
Thanks.
You can write two classes and use some toll like ant, maven or gradle to chose which file use for compiling with concrete Java version.
You can set the java compiler to compile against an older jdk (ie jdk 1.5) even if you use jdk 1.8. see javac source and target options
I think the short and easy answer is no.
See this thread: Can Java 8 code be compiled to run on Java 7 jvm?
You can use the java reflection api to check if methods exist in the jvm the code runs on. This allows you to make your code fail-safe even when a method or class is unavailable in the jvm. Doing this is very cumbersome however and I'm pretty sure it's not what your're looking for.
I have a task of fixing a program written in java, since it was crashing on start. I discovered that the problem was related to a discontinued class in the java library no longer available in 1.8.
Eventually I will find an alternative to the library but for right now I need to ship the program with a reference to an old java version NOT installed on the clients computer. What would be the most appropriate way of doing so?
Obviously you want minimal impact on the rest of the code base where you don't want to have to go modifying the imports that may be numerous in your code. So, if the Java version is not installed on the clients computer you'll need to include the class in the packaging of your application.
I would suggest that you create the package structure of wherever the missing class file currently resides such as java.io.x.y.z so you wont have to modify any of the import statements
e.g. import java.io.x.y.z.ClassName;
Then test test test to ensure it functions as you expect.
The JRE may be distributed with programs. So repackage your program to bundle a JRE and use the java binary from there to start your program.
If you use a wrapper script, this would be where to fix it.
You can use the new javapackager tool and specify the runtime option to include (bundle) a specific JRE.
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 would like to learn what native instructions Java's JIT compiler generates when it loads a class file. Is there any way of knowing it?
I am working in Linux on a 586 processor. And I am using Sun's JDK 1.6 update 21. Is there any tool that I can use to find out what I am looking for?
You probably need -XX:+PrintOptoAssembly, but you'd need a debug build of the JVM. The links to the binary distributions seem not to be available any longer, so you might have to build it from source: http://download.java.net/jdk6/6u10/archive/
If you're planning to try this with OpenJDK 7 as well, this might be of interest:
http://wikis.sun.com/display/HotSpotInternals/PrintAssembly