I'm not sure if you're speaking specifically about Hibernate, but if you are making the argument against ORMS generally, I feel like there are some counterargum

I'm not sure if you're speaking specifically about Hibernate, but if you are making the argument against ORMS generally, I feel like there are some counterarguments to the points you mention: > Every non-trivial long-lived application will require tweaks to individual queries at the string level I suspect that the difference in expectations here is about how many of the queries will need that, and whether the number of less sensitive queries is large enough that it's worth having less boilerplate for them even if some other queries do need to be able to drop into something lower-level. People will quibble about where this boundary is, and maybe the real disagreement is about where to drawn the line between "trivial" and "non-trivial" applications, but I don't think it's quite as obvious a conclusion that ORMS aren't useful in the general case as it sounds like you're arguing. > The proper way to build a data layer is one query at a time, as a string, with string interpolation This also isn't obvious to me. I can understand the advantages it provides, but it only lets you move the problem of conversion to native types in your language to outside the query layer, not eliminate it. I think there's a solid argument that splitting up the problem that way is better, but again, it seems more nuanced to me than there being one obvious answer. > The closer you are to raw JDBC the better How are you sure that it's impossible to provide any sort of useful abstraction here? There are plenty of other cases where using the lowest-level language possible isn't the obvious correct choice all the time; it doesn't sound like you're writing your code in raw assembly either, so there's obviously some utility in using higher-level abstractions.