I am new to java and I need to manipulate java bytecode for some purposes (see this). Java bytecode manipulation need following imports:
org.objectweb.asm
java.lang.instrument
I resolved org.objectweb.asm by downloading ASM package from asm website and related imports have been resolved.
I don't know how to resolve java.lang.instrument, My default ADT bundle hasn't it:
How do I resolve this import? Should I download any library? from where?
any help would be appreciated.
Thanks.
The java.lang.instrument package isn't available for Android. Just like AWT and Swing. Have a look at this question:
Android & Dalvik - Get the size of an object
But it makes sense. Android apps are written at the source level in Java, but they don't run on the JVM -- they run on the dalvik VM. There's no contract there that says they have to support the standard Java library.
Sorry :(
You're out of luck – find a way that does not rely on java.lang.instrument. java.lang.instrument is part of Java SE, but is not available on Android because of fundamental limitations of Dalvik.
The java.lang.instrument package was removed from dalvik core library, because this package makes a fundamental assumption that the execution format being used by the VM is a .class file. .class files do not appear on Android at all.
https://groups.google.com/forum/#!topic/android-developers/MR4W2roQ3Xw
Javassist is another tools to manipulate java bytecode. There is already someone who tried to use javassist in android. You might want to try it. As far as I know, bytecode manipulation on android runtime isn't possible, except in instrumentation (usually for testing). Manipulation on compile time is a different story, because java .class file generated first before converted to Dalvik bytecode. So if you modify .class file before being dexed, the dexed classes will be the modified one.
This article also worth reading, because it noted of ASMDEX which claim can manipulate DEX bytecode.
The java.lang.instrument package was removed. So you can't perform bytecode manipulation at runtime. However you can perform bytecode manipulation at build time with javaassist or ASM.
This sample project performs bytecode manipulation. It's usage is discussed here.
Related
When I analyze an APK, I see classes.dex and it supposed to contain my Java code and it does, why it also contains Java standard Library (java.io.) and the SDK platform (android.app.) which I used to compile the project.
Can anybody explain why are they included?
Basically, when we are writing any program we need to import the classes which are needed. So, likewise to run the program, it needs those code. The java.io or android.support are nothing but some codes written.
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'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.
In answers to this question, I learned that it is not possible to invoke the Java Compiler in javax.tools from a GAE app.
Does this limitation still apply?
If so, what are my options for compiling Java source code into loadable class files "on the fly"?
No, javax.tools is still not on the Appengine's JRE Class Whitelist.
The options you have are:
Compile somewhere else and than transfer and load .class files on appengine.
Try using one of embeddable Java compilers: Janino, JDT.
If you can live without Java, than you might try using BeanShell for Appengine.
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