Взлом базы данных

Как вариант сделать отдельное меню подключения с вводом адреса бд, логина и пароля, избежав тем самым внесения этих данных в код.

Вариант 1: в resources создаешь 2 файла: application.properties.example и application.properties application.properties добавляешь в .gitignore в корневой папке проекта Читаешь

Properties properties = new Properties();
try (InputStream is = getClass().getResourceAsStream("application.properties")) {
  properties.load(is);
}

Вариант 2: https://github.com/cdimascio/dotenv-java И использовать .env тоже в .gitignore и также сделать пример .env.example Лучше всего делать просто импорт переменных среды, это типа хорошая практика Это лучший вариант.

System. getenv(String name)

Передавать переменные окружения можно так (либо через докер/куб/GitHub Actions и так далее, если они используются)

MYSQL_VAR=my_mysql_var java -jar ...

Но команда останется в истории команд (надо написать внешний скрипт для запуска) $ history Вариант3: java -D<name>=<value>

System.getProperty(String key)

недостаток тот же Вариант4 (плохой): использовать args Обычно ещё в таких темах упоминают это

Когда люди изучают БД, то креденшенлы пихают в проект. Но учебный проект это котики и собачки. Разница между учебными проектами и реальными, где-то такая же, как между сидением на табуретке на кухне и держанием в руках бублика, представляя себе водителем и непосредственным вождением 40 тонника в сильний ливень на горной дороге и ночью Поэтому лично мне, непонятен контекст Для учебы, то что ты описываешь нормально, на нормальной работе тебя никто не подпустит самому настраивать базу данных, это вопросы инфраструктуры и вотчина других специалистов + программистов поопытнее, поработаешь, увидишь как что делается, разберешься в этом, тогда сведется как и что должно быть сделано. Это путь по которому идет большинство, азы во время учебы - остальное и практические моменты во время работы. Ведь джавист идет стажером/джуном на работу, да хоть и мидлом сразу, и все-равно потом еще минимум полгода доучивается как раз вот таким моментам, которые как правило дома не воссоздашь, да и не зачем То есть тебе вообще про это не нужно думать, только зафиксировать, что на рабочих проектах все по другому. База данных и данные это самое ценное, что есть в програмном продукте как правило. И вопросы безопасности на первом месте. Но возможно (ты контекст не предоставил, остается только гадать), у тебя есть ситуция, что по каким-то причинам, ты идешь не стандартным путем джава программиста, а хочешь создавать какие-то продукты НЕ имея опыта работы, не доучиваясь на работе (это как ординатура/интернатура у врачей), а сразу писать коммерческие продукты для небольших фирмочек или частные заказы. Это наверное единственный кейс, при котором твой вопрос "как спастись" валиден, но этот кейс валиден для < 0.1% джавистов. Ну тогда тебе набросали идей, креденшлы с кода убираются, БД настраиваешь и "прячешь", авторизация. Если кто-то пустит разработчика без опыта работы к себе на реальный проект, они должны отдавать отчет в последствиях, они свои приоритеты выставили -экономия выше безопасности

обычно такие данные выносятся за пределы приложения. Это может быть конфигурационный файл, либо переменные окружения Ну и корректным распрделение прав для той учетной записи которая используется в приложении, например не давать доступ к ненудным таблицам ил давать ограниченные права

ты используешь отдельно стороннюю БД + твой jar приложение?

При запуске приложения запросить имя/пароль у пользователя.