Hello, I've seen that you've also posted this question to Stack Overflow here, for the reference: http://stackoverflow.com/q/19868643/521799
jOOQ is a domain-specific language implemented according to the principles explained here: http://blog.jooq.org/2012/01/05/the-java-fluent-api-designer-crash-course/ This means that every "production" or "primary" from the DSL specification generates a Java interface with all the overhead this may generate in the class loader. Additionally, since jOOQ 3.0, record and row types with degree 1-22 were introduced (e.g. org.jooq.Row1, org.jooq.Row2, ... org.jooq.Row22). All of these elements are part of the API, which probably cannot be stripped down any further. Of course, you can try to manually strip down the jOOQ API and implementation, removing all the row types from it. Another entire statement that you might not need is the MERGE statement, which also has an extensive API. Then, there are the tools packages, which aren't strictly needed, specifically: - org.jooq.tools.csv - org.jooq.tools.json - org.jooq.types - org.jooq.util.[dialect] Also, you can try to remove a couple of classes from the org.jooq.impl package. The class names should be fairly straight-forward to help you decide whether something is needed. It would be interesting to see how far you get with such measures. This might be useful for Android users, too. Cheers Lukas 2013/11/8 <[email protected]> > I have a distributable open-source plugin for game servers (java-based) > that's very heavy on database interaction and I'm looking for a solid > query-building solution. I've been giving jOOQ a try because the database > abstraction appeals to my users, and the ability to export the final query > for debugging is appealing to me. > > However, the application itself doesn't yet need most of what jOOQ offers. > I really don't need any active record, any sql support outside of selects, > insert, deletes. Our plugin is 512kb, but with jOOQ shaded (using > minimizeJar) it grows to 1.5MB. That's a lot bigger and is going to lead to > a bunch of problems. I haven't even looked at how much more memory the > plugin uses when running. > > I haven't found another solution that's as flexible, so I'm searching for > a way to strip down the jOOQ classes we're shading into our JAR, so that we > can exclude features we don't (yet) need, but so far it doesn't seem > possible. > > If that's not possible, are there any alternatives I might look at? > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
