faster newInstance and setField via sun.misc.Unsafe

[dimzon]

enjoy

[aaberg]

Wow, this really looks promising. Unfortunately I can't get the tests to run!

I'm using Oracle java 1.7 on a Ubuntu box.

I think there is an error on line 24 of the UnsafeFieldSetterFactory. You should call field.getType instead of field.getClass, as that will just return the Field.Class instead of the type it represents.

But even after fixing this, many of the tests fail!

[dimzon]

All tests all passed now. Found many awfull code (seems like You doesn't care about thread-safety)...

[dimzon]

• some optimiation

HandCoded took 661ms
Sql2oTypical took 725ms (9.68% slower)

[aaberg]

Tested this by selecting 1,000,000 rows from a H2 database and parsing into pojos. Your implementation seems to give a descent performance increase of about 10-15 %.

We need to do something about the FactoryFacade class. The current implementation sets the setter-factories in the static constructor, which makes it hard to create unit testing that tests both the Unsafe-based implementation and the reflection-based implementation. Maybe each instance of Sql2o should have its own FactoryFacade?

I can see what you mean about thread-safety in the PojoMetadata cache... That is not good! I will create a ticket about it and get it fixed. Did you find any other examples of non-threadsafe code?

[dimzon]

We need to do something about the FactoryFacade class. The current implementation sets the setter-factories in the static constructor, which makes it hard to create unit testing that tests both the Unsafe-based implementation and the reflection-based implementation.

You doesn't need to unit-test whole DB->POJO sequence. Create unit-test against FieldSetterFactory interface and feed all known implementations to it. Same for ObjectConstructorFactory and MethodSetterFactory.

also current FactoryFacade is temporary solution, needs some refactoring.

Did you find any other examples of non-threadsafe code?

Yes, FutureDetector as example. Actually I believe You need strong refactoring wich breaks some public API. I have a serious expirience in ORM development, also with dealing with JDBC "quirks" etc. Also I found some algoritmic bottlenecks wich is hard to resolve without some refactoring.

[aaberg]

@dimzon You are of cause right about the unit-testing!

Could you take a look at pull request #69 ? I fixed the thread-safety issue for the PojoMetadata caching. I would really like your comment on it, if you don't mind?

[dimzon]

commited abstract thread-safe cache implementation

[dimzon]

@aaberg
need merge with Quirks - related refactorings from @aldenquimby before I can continue
please review code and merge

[aaberg]

Merged!