Tag Archives: Java 7

Copy object in Java (performance comparison)

This blog came about because I was looking into performance issue and profiling showed that a method that was copying objects was very slow. (NB: The fact that this method was called millions of times was an actual bug not the slowness of the copy routine.)

The method to copy object was performing field by field copy using class.getDeclaredFeilds() method to obtain all fields of the class and then doing copy recursively for all super classes. Code below shows entire thing:

public static void copyFieldByField(Object src, Object dest) {
copyFields(src, dest, src.getClass());
private static void copyFields(Object src, Object dest, Class<?> klass) {
Field[] fields = klass.getDeclaredFields();
for (Field f : fields) {
copyFieldValue(src, dest, f);
klass = klass.getSuperclass();
if (klass != null) {
copyFields(src, dest, klass);
private static void copyFieldValue(Object src, Object dest, Field f) {
try {
Object value = f.get(src);
f.set(dest, value);
} catch (ReflectiveOperationException e) {
throw new RuntimeException(e);

Profiling showed that this method spend 70% of it’s time in Field#copy() method. As it turns out that Class#getDeclaredFields() returns a copy of the Field[] array on every call, ouch! BTW, the JavaDoc of Class#getDeclaredFields() does not mention copy behavior at all.

List of approaches

Looking at the profiling results I started wondering what would be a better way to create a shallow copy of the object. Hence I needed to test performance of different approaches. For the simplicity I decided to look only on what is possibly with JDK 7 only (no fancy libraries) and came up with the following list:

  1. Clone object – implement Cloneable interface and publish clone() method
  2. Copy with copy constructor – copy fields from the source object directly in the constructor
  3. Copy via reflection (field by field)
    • getDeclaredFieds() as in original code
    • getDeclaredFields() cached, i.e. call it once and remember list based on the Class
  4. Serialization

    • Default serialization – just implementing Serializable
    • Custom serialization – implement Serialization and implement readObject() and writeObject() methods for reading and writing fields directly
    • Implementing Externalizable interface
  5. MethodHandles
    • Use MethodHandle#invoke(Object... args) method
    • Use MethodHandle#invokeWithArguments(Object... arguments) method
    • Use MethodHandle#invokeExact(Object... args) method

Notes on implementation

Entire project with source code and test results is available on github (copy-object-benchmark.git).

Benchmarks are written using JMH framework from OpenJDK. For each class tested there is a method in the benchmark class that simply invokes copy() method on the constant object representing the class. For example:

public Object copyFieldByFieldGetFieldsEveryTime() {
return FieldsCopy.INSTANCE.copy();
public Object copyFieldByFieldUseCacheFields() {
return CachedFieldsCopy.INSTANCE.copy();
public Object copyByClone() {
return CloneCopy.INSTANCE.copy();

Every approach from the list above was benchmarked for 2 cases:

  • Primitive fields
  • Object fields

Because most of the approaches would incur significant overhead via boxing/unboxing.

For every kind of copy method there is a class that extends common super class (i.e. BaseClass) and implements copy() method. Since there are 2 use cases tests had to be duplicated in 2 different packages.

One last thing that is worth mentioning before I show the results is the handling of MethodHandle#invokeExact() case. This method is very special when it gets to invocation. Here is an example:

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
class Base {
int x = 13;
class Derived extends Base {
public long m;
public class TestMH {
public static void main(String[] args) throws Throwable {
MethodHandle mh = MethodHandles.lookup().findGetter(Base.class, "x", int.class);
Derived obj = new Derived();
// mh.invokeExact(obj); => throws WrongMethodTypeException:expected(Base)int but found (Derived)void
// mh.invokeExact((Base) obj); => throws WrongMethodTypeException:expected(Base)int but found (Base)void
int value = (int) mh.invokeExact((Base) obj);

As you can see in order to call MethodHandle#invokeExact() it is necessary to match exactly arguments and return type of the method, otherwise such invocation will fail at runtime.

However it is not possible to know upfront all possible classes and return types if you want to write generic copy method. Therefore we need to adjust MethodHandle so it can be invoked in a generic manner. This is done by adjusting MethodType signatures of the MethodHandle as shown below:

private static MethodHandle prepareGetter(MethodHandle mh) {
return mh.asType(mh.type().changeParameterType(0, Object.class)
private static MethodHandle prepareSetter(MethodHandle mh) {
return mh.asType(mh.type().changeParameterType(0, Object.class)
.changeParameterType(1, Object.class));

Basically this erases original information about declaration class and return types and instead uses Object for both thus allowing calling MethodHandle#invokeExact() providing instance of any class and expecting result as Object.


I was running the benchmarks on my MacBook Pro laptop: OS X 10.9, 2.7 GHz Intel Core i7, 16 GB of RAM. Tests were performed on the following JDKs:

  • 1.7.0_25 (1.7.0_25-b15)
  • 1.7.0_45 (1.7.0_45-b18)
  • JDK 8 build 112 (1.8.0-ea-b112)

Results are reported as throughput (operations/ms) with biggest numbers being the best. All charts are in logarithmic scale.


  • JDK 1.7.0_25:
    Raw results are available here results-1.7.0_25.txt.

    So in this version of JDK the best 3 methods were:

    1. Clone
    2. Copy constructor
    3. Reflection

    Also MethodHandles are very slow comparing to other approaches.

  • JDK 1.7.0_45:
    Raw results results-1.7.0_45.txt.

    In the 1.7.0_45 release we see that MethodHandle#invokeExact() got much faster (~5x times) to the point that it made it to top 3 copy methods (for primitives case). Also MethodHandle#invokeWithArguments() got slower. But otherwise the rest remains the same.

  • JDK 8 build 112:
    Raw results results-1.8.0-ea-b112.txt.

    JDK 8 build 112 brings significant performance improvements over JDK 7 results in two areas:

    • Reflection
    • MethodHandles

    Most dramatic change was in the MethodHandler#invoke() case which now is more than 120x times faster! The changes were done originally proposed by John Rose on a JDK mailing list and implemented as part of the JDK-8024761: JSR 292 improve performance of generic invocation issue.

    Along the way MethodHandle#invokeWithArguments() got faster as well.


  • New JDK releases bring performance improvements
  • New JDK versions bring new functionality that can be used in place of old approaches (e.g. MethodHandles)
  • JVM is extremely good at optimizing existing code, i.e. reflection is still faster than invoke dynamic (at least for Object case)
  • Read JavaDoc but step through the code in the debugger and not just through your own code but also JDK code
  • Write performance tests upfront to know whether selected approach meets performance requirements
  • Run performance tests against new JDK versions to avoid/detect performance regressions


I’ve published second blog post Clone vs copy constructor – a closer look in which I analyze performance difference of clone and copy constructor approaches.

Where to put tools.jar in JRE 7?

If you are distributing JRE with your application and you happen to also distribute tools.jar as well. The you have probably copied tools.jar to the jre/lib/ext folder.

This is viable option and have worked for me in the past (i.e. with Java 5 and Java 6). However this does not work in Java 7. If you do this in Java 7 you won’t get system compiler instance for example (i.e. executing code javax.tools.ToolProvider.getSystemJavaCompiler() will return null)

What I found out (painfully) that in Java 7 you have to put tools.jar directly to the jre/lib folder!!!

When you do this you can execute javax.tools.ToolProvider.getSystemJavaCompiler() and get a compiler instance as expected.

Updated (2012-07-10):
Oracle has accepted bug report for this problem. You can see it in Oracle’s bug database as 7181951.

Updated (2012-07-14):
Oracle has closed the bug with the following evaluation:

Closing as not a bug. That behavior was neither specified nor intended.
Posted Date : 2012-07-13 15:57:50.0

So I guess it means that the only true place for tools.jar is the jre/lib folder!


In my previous post on Java 7 I’ve outlined some problems one might face when converting project to use it. Here I would like to outline issues I’ve discovered when I actually migrated code from Java 6 to Java 7.

Contrary to what I’ve been expecting, actual upgrade to Java 7 turned out to be bumpier. One of the reasons was converting code to use new Java 7 features. For that I’ve used NetBeans 7.2 RC1 and it’s “Inspect and transform” feature. (By the way Intellij IDEA also has capability of automatically converting code to Java 7)

Overall the tool did a great job and I was able to convert big project of several thousand classes in a matter of minutes. However since conversion resulted in more than 1000 classes modified it was not feasible to manually check all of them. As the result I’ve found about problems out only after nightly CI build have failed. Which brings me to the core of the post – a multi-catch conversion issues.

Multi-catch conversion pitfalls

So here is existing code from one of the classes before conversion to Java 7:

And here is the result of the conversion:

As you can clearly see the updated code is not semantically equivalent to the original code!!!

Before the change method rollbackTransaction(Throwable) would have been called in case of any exception (checked or unchecked), but after change it is called only in case if IOException or XMLStreamException is thrown.

As the result after such a change you get leaking transactions (zombies that are not closed). And this is kind of a bug that one would call a blocker or if you wish absolute top priority.

To me this conversion issue seems like a bug in NetBeans and a scary one. But it should be also a remainder to all of us to check the results of any automagic stuff that our tools are doing for us. 😉

Updated (2012-07-14):
I’ve submitted bug report to NetBeans team as Bug 215546. Let’s wait for evaluation on this one.

Is your project ready for Java 7?

Java 7 has been released last year, but how many of you use it in production or even in development environment? Have you even tried it at home? Why not?

Well, I’ll leave all this questions to the reader as in this post I would like to discuss issues that one might encounter when trying to upgrade existing project to Java 7.

Here is the list of questions I want you to ask yourself about your project:

  • Will it compile?
  • Will it run?
  • Will it execute with the same runtime semantics, i.e. will it run as before?

Some of the questions might sound silly but all they come from my attempt to upgrade existing project from Java 6 to Java 7.

Oracle has released interesting document Java SE 7 and JDK 7 Compatibility. This document defines Binary, Source and Behavioral compatibility policies as well as list exceptions to defined compatibility rules. What is interesting is that it defines incompatibilities between Java SE 7 and Java SE 6 as such:

Java SE 7 is strongly compatible with previous versions of the Java platform. Almost all existing programs should run on Java SE 7 without modification. However, there are some minor potential source and binary incompatibilities in the JRE and JDK that involve rare circumstances and “corner cases” that are documented here for completeness.

Compiling it

Back to our questions, so how can project not compile with Java 7 compiler (here I assume using -source=1.7 -target=1.7 compiler options)? The answer is source incompatibility which with Java 7 can have surprising incarnations. For example consider the following class:

class MessageService {
  String getMessage(String msgKey, Object...args);
  String getMessage(String msgKey, boolean includeKey, Object...args);

And it’s usage by some client class:

  messageService.getMessage("MSG108", false, arg1, arg2, arg3);

Here client attempts to invoke second method which allows him control whether or not message will have message prefix added. In this particular example client explicitly requests that he wants only actual message with prefix.

This code is perfectly OK for Java 6, but does not compile on Java 7. When I first saw it I went as far as to create bug report for Oracle (see 7115209), but as was expected Oracle closed the issue as “not a bug”. They provided explanation that this behavior is according to JLS and pointed me to the Java SE 7 and JDK 7 Compatibility document for explanation. And indeed this document contains issue named “Changes in Most Specific Varargs Method Selection” which describes in great detail the rationale behind the changes and use-cases.

So how can we fix code so it compiles. There are 2 possible solutions:

  1. Fix MessageService class definition so that client code compiles
  2. Change MessageService API and all clients that are using it (for example by creating two different methods getMessage and getMessageWithoutKey)

Which is the best approach depends on whether or not you have access to client code. In my case I didn’t have such luxury so I had to go with solution 1 which resulted in the following definition of the MessageService class:

class MessageService {
  String getMessage(String msgKey, Object...args);
  String getMessage(String msgKey, Boolean includeKey, Object...args);

As you can see the only different from the original declaration is that parameter includeKey is declared as Boolean instead of boolean. This is pretty cheap fix and will leave users of your class happy as they can continue using old API!

Running it

OK, so what about second question: “Will it run?”. The answer to this question basically depends on whether or not the libraries used in the project are ready for Java 7. This is especially true for libraries that manipulate bytecode. As described in the document in the section “Verification of Version 51.0 Class Files”:

Classfiles with version number 51 are exclusively verified using the type-checking verifier, and thus the methods must have StackMapTable attributes when appropriate. For classfiles with version 50, the Hotspot JVM would (and continues to) failover to the type-inferencing verifier if the stackmaps in the file were missing or incorrect. This failover behavior does not occur for classfiles with version 51 (the default version for Java SE 7).
Any tool that modifies bytecode in a version 51 classfile must be sure to update the stackmap information to be consistent with the bytecode in order to pass verification.

And that exactly what I observed with AspectJ library version 1.6.11 which failed at startup with the “java.lang.VerifyError: Expecting a stackmap frame at branch target 26 in method …“.

However luckily for me upgrade to version 1.6.12 solved the issue. The moral here is that you should check libraries that are in use within your project! 😉

Checking results

Last but not least question about runtime semantics. Surprisingly I came across an issue when running unit tests as some of the tests started to fail on Java 7 but are fine on Java 6. The answer to this behavior could also found in the document, section “Order of Methods returned by Class.get Methods can Vary”:

In JDK 7, build 129, the following reflective operations in java.lang.Class changed the fixed order in which they return the methods and constructors of a class:


This may cause issues for code that assumes (contrary to the specification) a particular order for methods or constructors.

So with this change the order of tests execution changed and as the result showed actual problem with my code – i.e. dependencies between tests. Which is btw an anti-pattern as defined in the book by Gerard Meszaros xUnit Test Patterns: Refactoring Test Code. Thus I was alble to fix actual problem looking at the symptoms! 🙂

Moral of this story: be ready to spend some effort when upgrading to Java 7. It is better to start early and prepare infrastructure without conducting actual update. For instance I started using Java 7 on the CI server which actually showed all the issues listed above and now I’m pretty certain that actual switch from Java 6 to Java 7 will be smooth.

I hope this information will be useful for some of you. And I’m waiting for your feedback!

Updated 2012-07-18:

Beware that JDK 7 uses new version of JAXB. As of this writing latest JDK version from Oracle is 1.7.0_05 which is shipped with the JAXB 2.2.4u1.

This version of JAXB contains a bug JAXB-871 which leads to broken serialization of the objects (if base class property is overridden by any single class, it won’t be delivered to all other sub-classes of the base class sub-classes)!!!

The workaround for this issue is to use standalone version of JAXB that does not have it. For example one can use version 2.2.3u2. Just add jars into classpath of your application!

Note: In order to find out which version of the JAXB and JAX-WS is in your JDK installation run the following commands:

jdk_home/bin/wsgen -version
jdk_home/bin/xjc -version

Here is sample output:

c:\Program Files\Java\jdk1.7.0_05\bin>wsgen -version
JAX-WS RI 2.2.4-b01

c:\Program Files\Java\jdk1.7.0_05\bin>xjc -version
xjc 2.2.4

Latency Tip Of The Day

"Nothing is more dangerous than an idea when it is the only one you have." (Emile Chartier)

Psychosomatic, Lobotomy, Saw

"Nothing is more dangerous than an idea when it is the only one you have." (Emile Chartier)


"Nothing is more dangerous than an idea when it is the only one you have." (Emile Chartier)

Mechanical Sympathy

"Nothing is more dangerous than an idea when it is the only one you have." (Emile Chartier)