А есть ли годный ORM для Java?

Ты настолько толст, что не знаешь о Hibernate?

linq нету, есть jpa и jpql

Знаю, это ужасно. Кстати раскопал Scala ORM (SORM) - автор на Хабре приводил примеры и выглядело Ъ.

JPQL в продакшене есть?

Возможно у тех кто плюется на Hibernate, и фантазирует о смене движка ORM.. На деле, JPQL это урезанный HQL, а HQL - в продакшене есть.

есть еще Querydsl, но о продакшене вопрос будет открыт. Я б не связывался

Таки да, SORM выглядит Ъ, но раз такая пьянка, с JPQL в целом жить можно.

Может быть вам будет интересен: http://code.google.com/p/mybatis/

пример linq из википедий:

var q = from o in db.Orders from c in db.Customers
    where o.Quality == «200» && (o.CustomerID == c.CustomerID)
    select new { o.DueDate, c.CompanyName, c.ItemID, c.ItemName };

spring data jpa

да он просто огромен

JPQL в продакшене есть?

ЧЕ?

А что же еще в продакшне то? HQL? С него спрыгивают уже давненько

Оптимальный вариант для РСУБД - Spring Data + JPA. Для чистого JavaEE тоже вроде городили подобное, CDI Query кажись

Есть mybatis, ещё когда-то использовал nanorm - он самый лёгкий и удобный, но сейчас он уже помер.

Hibernate.

В 3 аннотации делается. Тебе понравится.

Без raw SQL?

В JPA есть такая прикольная штука - по сущностям генерятся всякие доп-классы с константами-названиями полей. В связке с Criteria API получаем полностью статически типизированный ORM. По-моему годно. В Hibernate такого не видел.

А HQL, JPQL это всё неудобная гадость. SQL и то удобней.

Есть. JPA 2.x и JPQL с декабря 2009 года в Java EE присутствует. То есть немногим более 4 лет доступен API ORM в стандартной реализации.

еще раз расскажу про jOOQ. Мне понравилось.

Да, без raw-sql

В настройках хибермейта выставляй автогенерацию схем по объектам.

ORMLite

Книжка «Разработка приложений Java EE 6 в NetBeans 7» Дэвида Хеффельфингера вразумит тебя.

Criteria API

Так ведь придется и запросы в нем писать. У меня сделать их хоть сколько-нибудь человекочитаемыми не получалось, да и не для того они.

Это больше для динамически формируемых запросов.

Это не только для динамически формируемых запросов, а ещё и для будущих изменений схемы (меняется схема - с необходимостью нужно переделывать все места, которые затронуты данным изменением - компилятор просто не соберёт места, написанные под старую схему), портируемости (возможно подкладывание какой-нибудь не RDBMS) итп. Реальность, конечно, сложнее, но, в целом, код более контролируемый. Да, я помню, что code coverage в идеале должен быть over 146% :)

Hibernate мощный, но все же низкоуровневый достаточно. Сравни его с ORM у Rails где SQL нужен только для уточнения подзапросов.

посмотрите в сторону jOOQ

PS/ а я уже советовал, оказывается :)

slick же

Для валидации того же JPQL можно использовать @NamedQuery, конечно, не во время компиляции, а во время деплоя но и Criteria API требуют пересборку классов. В любом случае эта проблема удачно решается через автоматизированное интеграционное тестирование в обоих случаях.