Adam, > I am pretty much aware of the pros/cons of the internalisation. I have used > it in the past and have seen some impressive memory savings (this depends on > the data model and the structure of the data itself however). As far as the > performance improvements go this a bit mode difficult to quantify. I guess > what I am trying to say is let's have an option (generator flag) to use it > or not. Depending on your application and the data model you can decide if > you want to use it.
I'll definitely do some further reading on the subject. Given that Java 7 can GC interned strings, my doubts have disappeared a little. Making this an option wouldn't hurt Java 6 users, then. Anyway, jOOQ shouldn't make too many assumptions about the client data model or the underlying data histograms (i.e. even or not so even distribution of unique IDs within a column). Hence, the choice about which columns are interned should be done by the user. I'm thinking about adding yet another code-generation configuration that uses regular expressions for column name matching. > One other thing. In not too distant future (hopefully) you will have JavaFX > apps running on hand-held devices under iOS, Android and Windows where the > memory will be more of an issue than on your typical web or a desktop app. I > do not think people will be using TopLink or Hibernate there :-). Heh, ok. But if you're really short on memory, maybe Apache DbUtils wouldn't be such a bad choice, either... :-) -- 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.
