Programmatic API to generate a config file

[stephanenicolas]

Hi @j256 ,

I could work on the gradle plugin for Android :
https://github.com/stephanenicolas/ormlite-android-gradle-plugin

Currently the plugin is still immature. But it can work for most apps I think. It still needs more configuration and more adaptation to the gradle life cycle for android.

Nevertheless, it works only by using command line to drive the OrmLiteConfigUtil class. It was really the simplest way to do it. But a real API would be so much better !

https://github.com/j256/ormlite-android/blob/master/src/main/java/com/j256/ormlite/android/apptools/OrmLiteConfigUtil.java

Here are some concerns with this class :

• every method is static, it doesn't allow extension by inheritance
• most methods are static and you need to extend the class to use them
  For this, it would be nice to have a simpler standard java class with public, protected and private methods.

Also, the class :

• is not customizable enough, it does too many things by itself and should not assume any project structure, like trying to find both java source files and the raw folder from a common root, then also loading the classes into memory from jar files, etc..
• for gradle we need to pass you :
  ** one or more folders that contains sources
  ** a destinationDir to write to
  ** the name of the config file in it
  ** glups, the hard part ! : the classpath

we need to feed you with a classpath because you load the classes and use them. (This problem would not be present with an annotation problem, but annotation processors have also their disadvantages.)

Also, we need to configure the classpath as with gradle, different classpaths can be defined for different flavors.

But then, we will run into a new problem (I know because I tried) : the annotation classes used in ormlite source code, will not be the same as the annotations classes used in the source code of the app. And ORM Lite is not able to recognize those annotations because they live in a different class loader.

Ways to workaround this would be

1. share the classpath as you currently do : the utility app must have the classes to manipulate in its classpath. But that is harder to do programmatically, and may also look a bit awkward : the class loader being used as a kind of class storage shared by the app and the plugin
2. make it possible to recognize annotations not by classes but by names.

Solution 2 is the most clean but can be tricky on the performance level. Maybe with a strategy pattern it can be smoothened. Solution 1 is a bit awkward, but can be the simplest for developers.

And this can be largely worked around with an annotation processor, but it also comes with some complexity, but probably the best way to do it.

[NCrouther]

I took a crack at automating this with an annotation processor. #45

[kpgalligan]

Annotation processing is interesting. Took a quick look at the PR, but
would need to dig more heavily and test.

I did a really simple solution for 49 that reads and saves on first run
rather than compile time. Based on db version number. Positive is that
it'll run automatically. Negative is slow first run for DB.

I've been toying around with annotation processing and code to copy values
from the cursor into model objects. Generated can copy values about twice
as fast as reflection. Would be a pretty significant change, but hoping
somebody gets the urge to try it ;)

In any case, should pull the config gen code in to a version and see if we
can get some people testing.

On Fri, May 8, 2015 at 11:22 PM, NCrouther notifications@github.com wrote:

I took a crack at automating this with an annotation processor. #45
#45

—
Reply to this email directly or view it on GitHub
#40 (comment)
.

Kevin Galligan
http://about.me/kpgalligan

[NCrouther]

Thanks for taking a look. Let me know if you have any questions. The big area to test would be to hammer on it with incremental compilation; I saw plenty of weirdness when changing annotated files in eclipse. I think all cases are handled properly, but be on the lookout for any spurious warnings/errors raised by the annotation processor during incremental builds.

I'd also definitely be interested in collaborating on expanding the use of annotation processors to eliminate more runtime reflection. I greatly prefer the ORMLite style to the other Android ORMs such as greendao, so if we can get comparable performance, it will be a slam dunk.

[kpgalligan]

Where did you learn the annotation processing stuff?
On May 9, 2015 6:37 PM, "Nathan Crouther" notifications@github.com wrote:

Thanks for taking a look. Let me know if you have any questions. The big
area to test would be to hammer on it with incremental compilation; I saw
plenty of weirdness when changing annotated files in eclipse. I think all
cases are handled properly, but be on the lookout for any spurious
warnings/errors raised by the annotation processor during incremental
builds.

I'd also definitely be interested in collaborating on expanding the use of
annotation processors to eliminate more runtime reflection. I greatly
prefer the ORMLite style to the other Android ORMs such as greendao, so if
we can get comparable performance, it will be a slam dunk.

—
Reply to this email directly or view it on GitHub
#40 (comment)
.

[NCrouther]

This tutorial got me started: http://hannesdorfmann.com/annotation-processing/annotationprocessing101/

I also learned a lot by examining the source for: https://github.com/JakeWharton/butterknife

StackOverflow had a lot of great information about gotchas: http://stackoverflow.com/questions/tagged/annotation-processing

Unfortunately, much of it was trial and error and Googling problems as they came up.

[kpgalligan]

We actually ran the Droidcon NYC last year. Our video wasn't great,
though. JW gave a talk on annotation processing. Still need to dive into
it:

https://www.youtube.com/watch?v=tRmJm2_qytM

I want to review this: https://github.com/yahoo/squidb

Haven't had a chance yet to dig into it and see what its doing. I'm a
little wary of the generated code, as you're regularly using classes
derived from your own templates, which I think is disorienting. GreenDao
is totally weird. You actually write builder code to generate objects, and
adding your own code to your models is clunky. There was a performance
benchmark project that claimed 12x performance difference, but it was super
shady in how it was set up. See my blog post about:
http://kpgalligan.tumblr.com/post/111719199393/ormlite-android-performance

However, I did run my own tests with hand-rolled RowMapper's for OrmLite,
and there is a significant performance boost. I also suspect there might
be issues with lots of temp object creations that could be avoided. It'll
be a deep dive to replace that plumbing, but I think it would be well
received.

I also think something that will allow join queries in an efficient way
would be very helpful. To discuss.

On Sat, May 9, 2015 at 8:14 PM, Nathan Crouther notifications@github.com
wrote:

This tutorial got me started:
http://hannesdorfmann.com/annotation-processing/annotationprocessing101/

I also learned a lot by examining the source for:
https://github.com/JakeWharton/butterknife

StackOverflow had a lot of great information about gotchas:
http://stackoverflow.com/questions/tagged/annotation-processing

Unfortunately, much of it was trial and error and Googling problems as the
came up.

—
Reply to this email directly or view it on GitHub
#40 (comment)
.

Kevin Galligan
http://about.me/kpgalligan