IMHO & AFAIK

VVS_AMD1) Нужно ставить JRE

JRE нужно НЕ для JNI,а для Java
Странное желание "переходить на java" и НЕ ставить JRE.
Любой врачь без проблем по фотографии дигноз поставил бы.
VVS_AMDJNI удалось взаимодействовать только с 32-битной JVM.

Не верю ( C )
Если Host-приложение 32-битное, то логично, что и DLL (JVE) можно грузить только 32-битные (ограничение Windows)
Если Host-приложение само 64-битное, то..... в общем аналогично )))

Хотите мешать 32 и 64 бита в одном приложении - сделать можно, но зачем? Любое средство между-процессорного взаимодействия. Можно родными средствами Windows (например COM), можно родными средствами Java - JRMI.

VVS_AMD2) Рядом с exe-шником будет валяться папка classes с байт-кодом java. Если бы можно было хотя бы jar собрать...

Кто мешает собрать JAR ?
См. ответ на Вашу притензию N 1

VVS_AMDВ общем, если можно сделать DLL, то было бы идеально...

Нет.
Был бы идеальный четерехколесный велосипед. По ступенькам ездить может и можно, но
"Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно. Над Вами потешаться будут" ( C )

Ну и гугле для поиска Java compiler to native code никто не отменял. Если уж хочется пересаживаться на велосипеды с квадратными колесами.

Постараюсь пояснить свой пред. ответ VVS_AMD:

Есть есть решение переходить Delphi -> Java, то 99% притензий, относятся к сиптомам когнетивного дисонанса. Не желание ставить JRE и все прочее... это такие мелочи на фоне вселенских проблем, что их даже обсуждать не хочется. Нет, можно конечно обойтись и без JRE - только это будет уже "не натуральная" JAVA, а что-то генно-модифицированное. И как такая экзотика аукнется в заключительный момент, предсказать практически не возможно

Основаня проблема будет, исключительно придумать и реализовать удобный API между "старыми" модулями на Delphi / Pascal и "новыми" на Java. А тут понятно, что извините, но скорее с ООП произойдет полный облом. Т.к. форматы "объекта" в Delphi и Java будут отличаться. И толи каждой твари городить по паре: для __всех__ объектов в приложении делать и Delphi реализацию и Java proxy, но для большого проекта мне финансовые затраты на такой подход совершенно не представить (например Oracle Customer Care and Billing так и переходил, для всех copy book'ов было две реализации: Cobol и Java). Толи что-то придумывать другое (напрммер я бы на месте Oracle в случаее CC&B не манильцев бы работой по кодированию copy book'ов занимал, а за 1-2 месяца банально написал бы коде-генератор для генерации copy book'ов. Оно конечно было бы менее "социально ответственно" ( TM ), но зато на два порядка дешевле и меньше ошибок)

и так далее....

А придумать автоматизацию "поставить JRE" это вообще не проблема. Да и ставить JRE не сильно нужно, достаточно просто директорий с JRE в подкаталог положить и при старте приложения path обновить. Т.е. от 1 до десятка строк на Delphi. В общем, 95% вопросов и "проблем" совершенно надуманны

p.s. сорри за много букв