Earlier I had blogged about the ability to create new classes from scratch in .NET.
I was looking for something similar to Reflection.Emit() in Java. Found a few examples on the web that use the Java compiler to compile source code dynamically and use Reflection to execute the methods.
http://www.javaworld.com/javaworld/jw-06-2006/jw-0612-dynamic.html?page=5
http://www.rgagnon.com/javadetails/java-0039.html
Other option is to use byte-code manipulation libraries such as BCEL, ASM, etc. A good list of open source byte code libraries are given at:
http://www.java-opensource.com/open-source/bytecode-libraries.html
Showing posts with label Reflection. Show all posts
Showing posts with label Reflection. Show all posts
Tuesday, May 11, 2010
Tuesday, November 13, 2007
Reflection in Java-XML binding frameworks
Almost all Java-XML binding frameworks use Java reflection to map Java objects to XML documents. I had used Castor and XMLBeans in our projects and were satisfied with the performance of both of them.
Recently a friend of mine told me that he had reservations on using Castor as it uses Reflection and hence cannot be used in high-performance applications. I contemplated on this and felt that some basic amount of reflection code would be present in any XML-binding framework; or how would the API call 'set' methods on Java objects during unmarshalling?
I found this discussion on the net that explains this same fact.
Snippet:
Castor will still use some amount of reflection (mainly to set values onto your domain objects) even if you are using a mapping file (a binding file is used during code generation only).
Having said that, let me add one thought. At the time most of these articles have been written (2001 to 2002), the use of reflection introduced some performance penalties, noticeable to some degree.
Since then, a lot of time and effort has gone into improving the JVMs/JDK/compilers to lessen this impact further and further. In my personal view, with the event of JDK 1.4 (and even more so with Java 5)
this problems have been addressed sufficiently in that I would not call the use of (moderate) reflection an issue any more. If use of reflection would still be an issue, frameworks like Spring and some of their most
powerful features (run-time AOP through Spring interceptors) would not have been adopted by the market as it happened in the last one or two years.
Btw, in case this is not clear enough, using a mapping file instead of Castor's 'introspector' to establish mappings between the Java domain classes and the XML artefacts does not really improve Castor's
performance, as both modes will cause Castor to use reflection to establish what methods to use on your Java objects to set a value, to get a value (from an instance variable) or to add a value to a collection member. Bear in mind that these activities happen at start-up time only, and thus once and once only.
At run-time, when e.g. unmarshalling an XML document to a predefined object hierarchy, Cstor will (and has to) use reflection to ...
a) create object instances (using Class.newInstance())
b) set and get values into/from your instance variables (Method.invoke())
Recently a friend of mine told me that he had reservations on using Castor as it uses Reflection and hence cannot be used in high-performance applications. I contemplated on this and felt that some basic amount of reflection code would be present in any XML-binding framework; or how would the API call 'set' methods on Java objects during unmarshalling?
I found this discussion on the net that explains this same fact.
Snippet:
Castor will still use some amount of reflection (mainly to set values onto your domain objects) even if you are using a mapping file (a binding file is used during code generation only).
Having said that, let me add one thought. At the time most of these articles have been written (2001 to 2002), the use of reflection introduced some performance penalties, noticeable to some degree.
Since then, a lot of time and effort has gone into improving the JVMs/JDK/compilers to lessen this impact further and further. In my personal view, with the event of JDK 1.4 (and even more so with Java 5)
this problems have been addressed sufficiently in that I would not call the use of (moderate) reflection an issue any more. If use of reflection would still be an issue, frameworks like Spring and some of their most
powerful features (run-time AOP through Spring interceptors) would not have been adopted by the market as it happened in the last one or two years.
Btw, in case this is not clear enough, using a mapping file instead of Castor's 'introspector' to establish mappings between the Java domain classes and the XML artefacts does not really improve Castor's
performance, as both modes will cause Castor to use reflection to establish what methods to use on your Java objects to set a value, to get a value (from an instance variable) or to add a value to a collection member. Bear in mind that these activities happen at start-up time only, and thus once and once only.
At run-time, when e.g. unmarshalling an XML document to a predefined object hierarchy, Cstor will (and has to) use reflection to ...
a) create object instances (using Class.newInstance())
b) set and get values into/from your instance variables (Method.invoke())
Labels:
Castor,
Java-XML,
Reflection
Wednesday, June 01, 2005
Use of Reflection in .NET to create classes at runtime (from scratch)
Just as reflection can be used to retrieve and interpret metadata, it can
be used to construct and "emit" it. The classes found in the System
.Reflection.Emit namespace allow metadata for new types to be generated
in memory and used at runtime. In fact, you can dynamically create
an entire assembly, its classes and methods, and the IL code behind them.
The "in memory" assembly can then be used by other applications.
Good examples and articles can be found at :
http://geekswithblogs.net/johnsPerfBlog/articles/49829.aspx
http://olondono.blogspot.com/2008/02/creating-code-at-runtime.html
http://www.code-magazine.com/Article.aspx?quickid=0301051
Another cool example that reads a text file and compiles and executes the class is available at:
http://vbcity.com/blogs/jatkinson/archive/2010/04/24/dynamically-read-compile-and-run-source-code-from-a-text-file.aspx
be used to construct and "emit" it. The classes found in the System
.Reflection.Emit namespace allow metadata for new types to be generated
in memory and used at runtime. In fact, you can dynamically create
an entire assembly, its classes and methods, and the IL code behind them.
The "in memory" assembly can then be used by other applications.
Good examples and articles can be found at :
http://geekswithblogs.net/johnsPerfBlog/articles/49829.aspx
http://olondono.blogspot.com/2008/02/creating-code-at-runtime.html
http://www.code-magazine.com/Article.aspx?quickid=0301051
Another cool example that reads a text file and compiles and executes the class is available at:
http://vbcity.com/blogs/jatkinson/archive/2010/04/24/dynamically-read-compile-and-run-source-code-from-a-text-file.aspx
Labels:
Reflection
Subscribe to:
Posts (Atom)