I'd like to merge several java classes into one. I've read ASM documentation and this http://www.jroller.com/eu/entry/merging_class_methods_with_asm but I can't understand how I can achieve my goal.
Are there more detailed examples about this?
Thanks
from java 1.5 there is a feature called instrumentation which enable you to manipulate byte code of a program during runtime. In addition, you can also manipulate byte code while the class loader loads specific class to the JVM memory. the ASM framework provide you tools to manipulate byte code easily by converting byte code assembler to something readable and adding some utilities to simplify your work. notice that manipulating byte code is very advance technique and you really need to know about the JVM and byte code before doing it.
I personally suggest you will do the ideas that appear above. but if you still presist doing it i suggest you read about instrumentation here: http://www.javalobby.org/java/forums/t19309.html
and than deep dive to ASM or javaassist framework: http://sleeplessinslc.blogspot.co.il/2008/07/java-instrumentation.html
i think java assist is easier to i suggest working with that.
i hoped i help
Related
I'm starting a project that will have to instrument java applications for coverage purposes (definition-usage of variables, etc). It has to add trace statements and some logic to the application and maybe remove statements.
I have searched for ways of instrument Java code and what I always find is about bytecode instrumentation.
My question is: It's the only way to instrument Java applications? There is any other way to do that? What are the advantages of bytecode instrumentation over the others?
I'll probably use the bytecode solution, but I want to know what are the problems with the other approaches (if any) to decide precisely.
Thanks!
The other method close to changing bytecode is using AOP (Aspect Oriented Programming).
The main library is AspectJ which also mostly defines the area.
The third option that might be interesting (since you are just starting out with the program) is using Spring.
It means you will have to learn a bit about IOC (inversion of control) but it basically means that instead of creating your objects yourself you let spring do it for you, and it has it advantages because when spring is incharge of the creation it can add all sorts of things in the creation process without you having to really declare it all yourself in aspectj.
In terms of complexity I would probably rate it:
spring (easiest)
aspectj
bytecode instrumentation (hardest)
but it's exactly the other way around when talking about capabilities (power). for example doing something like substracting code is only possible using the last one (I think)
You should definitely check out AspectJ
From what you describe you will be able to do what you want with it.
Doing bytecode instrumentation yourself is absolutely possible but it much more complicated.
I think you should check out AsepctJ first and got back to do bytecode instrumentation yourself as last resort.
See my paper on building coverage tools using program transformation engines. This approach has the advantage that it can be used on arbitrary programming languages. In addition, it sees the source code the way the programmer sees it, not as compiled byte codes (as generics get more complex, and get ground into finer byte codes, it gets harder to understand that source code by inspecting the byte code).
It is perhaps worth noting that program transformation generalizes aspect-oriented programming.
iam planning to develope one application, which will take java byte code or class diagram or metamodel as an input and produces the source code according to package structure.
But i need some suggestions like,
How to start this application, mean do there any api that convert the metamodel or byte code to source code.
You can check with Jdec framework in that case.It is doing the following functionality:
Selective Decompilation of a class file
Disassembling a java class
It is open source.
http://jdec.sourceforge.net/
I think it might be a good start.
Not sure if BCEL is what you are looking for but it's worth taking a look.
When I personally need to decompile some java bytecode I'm using JAD.
Also when you're looking for an general introduction to java bytecode for an better understanding try the two links in the comments (I'm restricted to two links per answer so I apologize the inconvenience).
If I wanted to create a new language for Java I should make a compiler that is able to generate the byte-code compatible with the JVM spec, right? and also for the JDK libraries?
Where can I find some info?
Thanks.
Depends what you mean by "create a new language for Java" -- do you mean a language that compiles to bytecode and the code it generates can be used from any Java app (e.g. Groovy) or an interpreted language (for which you want to write a parser in Java)?
If it is the former one then #Joachim is right, look at the JVM spec; for the latter look at the likes of JavaCC for creating a parser for your language grammar.
I would start with a compiler which produced Java source. You may find this easier to read/understand/debug. Later you can optimise it to produce byte code.
EDIT:
If you have features which cannot be easily translated to Java code, you should be able to create a small number of byte code classes using Jasmin with all the exotic functionality which you can test to death. From the generated Java code this will look like a plain method call. The JVM can still inline the method so this might not impact performance at all.
The Java Virtual Machine Spec should have most of what you need.
An excellent library for bytecode generation/manipulation is ASM: http://asm.ow2.org.
It is very versatile and flexible. Note however that it's API is based on events (similar to Sax parsers) - it reads .class files and invokes a method whenever it encounters a new entity (class declaration, method declaration, statements, etc.). This may seem a bit awkward at first, but it saves a lot of memory (compared to the alternative: the library read the input, spits out a fully-evolved tree structure and then you have to iterate over it).
I don't think this will help much practically, but it has a lot of sweet theoretical stuff that I think you'll find useful.
http://www.codeproject.com/KB/recipes/B32Machine1.aspx
There is a certain library I would like to make use of from Java.
The library itself is written in Pascal and compiled down to a DLL. I have read access to all relevant source code (it is free and open source) but it is unlikely I could influence any change proposals to the original code of the library. I have very little Pascal knowledge or experience. The library itself deals to a certain extent with passing in and getting back structures in memory. (If it were C, the functions would take and return struct pointers. I am unfortunately unaware of the equivalent names in Pascal.)
What I would like to make is a Java wrapper to this library. I would like to be able to make calls to these functions. I have read a number of tutorials about the Java Native Interface. What makes some sense is how to interface these functions. What does not make sense to me is how I am meant to deal with these structures in memory.
I would really appreciate if someone could help me figure out how to do this, or point me towards a good resource for it. What I've read so far mostly excludes or glosses over what seems to be the most important part for what I need, dealing with these structures I have in memory.
Thank you all.
Based on my experience, I'd avoid JNI (way too complicated) & use JNA instead.
a colleague pointed me the other day to BCEL which , as best I can tell from his explanation and a quick read, a way to modify at run time the byte code. My first thought was that it sounded dangerous, and my second thought was that it sounded cool. Then I gave it some more thought and I recalled the codinghorror post on monkey-patching and realized that this was basically the same thing. Has anyone ever used BCEL for anything practical? Am I right that this is basically run time monkey patching, or am I missing something?
From BCEL's FAQ:
Q: Can I create or modify classes
dynamically with BCEL?
A: BCEL contains useful classes in the
util package, namely ClassLoader and
JavaWrapper.Take a look at the
ProxyCreator example.
But monkeypatching is... uhm... controversial, and you probably shouldn't use it if your language doesn't support it.
If you have a good use case for it, may I suggest embbededing Jython?
It's a bit more low-level than classic monkey patching, and from what I read, the classes already loaded into the VM are not updated. It only supports saving it to class files again, not modifying run time classes.
You might look at it as monkey patching. I prefer not to use it (maybe I never faced a good use case for it?), but be familiar with it (to have an idea how Spring and Hibenrate use it and why).
See this realworld example: Jawk - Compiler Module. BCEL is useful for "compilation" ur custom language.
BCEL does not support monkey patching, it just manipulates with bytecode and possibly loads it in a custom classloader. However you can implement monkeypatching on JVM using library like BCEL and Java agent. The Java agent (loaded by -javaagent argument) can access the Instrumentation API and modify loaded classes. It is not hard to implement it via some bridges.
But remember:
I am not sure if having to use -javaagent is something you want.
In any language, monkey patching can lead to badly predictable behavior.
You can modify a method. In theory, you can also add some method, but you need to compile the project against modified (patched) classes. I think this would cause a lot of pain and it is not worth of it. There are alternative languages that support it (e.g. Groovy) or suppport something similar (e.g. implicit conversions in Scala).
It is better to design your API well than to use monkey patching. It may be rather useful for third party libraries.