What would be the fastest way of copying data between Java objects?

I have various sets of Java objects, some of them pojos generated from JAXB tools, some of them domain classes etc.. In a large application, I need to get data from one set of objects and put into another set of objects which have different capabilities to use the data.

There are various methods of doing this: object mapping frameworks being an obvious choice. However, most of these frameworks with a solid code base and community, use reflection.(dozer for example)

I've been using a combination of adapters which adopt pojos and more complex java classes to visitor pattern, so that a visitor walking on the adaptor walks over one set of objects, and in the process creates another set of objects (the objects usually have parent/child/tree type of references) Especially when pass by reference is used rather than creating new Strings etc, this should be the fastest method available.

Can you think of any other method? Some sort of serialization to a byte array in memory, then deserialization maybe? Could it beat visitor based开发者_如何学Go copies in terms of performance? Am I being unfair to reflection based approaches like Dozer? This is a key operation in the application, so any improvements are likely to improve overall performance significantly.

The visitor pattern should be pretty near optimal for performance. Anything involving serialization is going to be worse because of the overhead of any kind of generalized mapping.

I'm not specifically familiar with dozer-- but reflection doesn't have to be such a huge hit if it is used essentially to automate the code writing you are doing by hand; that is, if it generates a class (or equivalent logic tree) a single time to define the copying operation and then runs this repeatedly. The reflection cost is amortized over a large number of operations and becomes negligible.

At the end of the day, you really need a benchmark and minimum requirements.

If you already meet the minimum time requirements for the copy, you can avoid changing any code and move on. If you don't, when you meet the minimum requirements you can stop.

For every "fast" way, there is always some other way that might be a bit faster. Stating minimum requirements quickly tells you if this needs to be fast (or you're just optimizing prematurely) and when to stop putting in resources to make it even faster.

Crafting a good java benchmark is not overly difficult, but do read up on it before you attempt it (as crafting a bad benchmark is ridiculously easy).

Adapter of Facade pattern will be a good idea. The less you copy data around - the better. Also, it is a good idea to make your data immutable, so you can avoid concurrency issues in the future.

I would stay away from in-memory serialization, especially with changing format.

Same goes to reflection. If you have a lot of objects and don't want to write adapters by hand, it is much better to use model driven approach and generate said adapters as part of your build process.

If all you're concerned about is transferring data, and not actually creating a composite object of fields from two different classes, then I suggest a facade. The facade will be your dispatch into several different objects and return one data transfer object (DTO) from the two.

http://en.wikipedia.org/wiki/Facade_pattern

Some people would argue since you're not executing functionality, but returning a composite, then this would be called a composite or wrapper or adapter, but either way, I would still go with that approach.

I usually start here:

http://www.javacamp.org/designPattern/