- Метод 1: Для минимальной версии JRE это будет сложно. Самый простой способ - просто потребовать ту же версию, с которой вы работаете, или позже, например, JRE 6.x.x или выше.
- Метод 2: Установите несколько JDK, сделав их доступными в Eclipse, и просто измените версию, для которой вы строите, каждый раз запуская набор тестов вашего приложения, и проверяя, все ли они пройдены. Самая ранняя версия JDK, которая позволяет пройти все ваши тесты, - это самая низкая JRE, с которой он может работать. Просто успешной компиляции вашего приложения недостаточно , потому что в предыдущих версиях JRE / JDK могли быть ошибки, которые допускают успешную компиляцию, но не допускает правильное выполнение программы.
- Метод 3: Всегда требуйте последние версии на стороне клиента, потому что Oracle постоянно исправляет дыры в безопасности, и, в конечном счете, может быть лучше потребовать последние версии, если у вас есть такой контроль, на стороне клиента.
Что касается оперативной памяти, это просто. Когда JVM запускается, он устанавливает «максимальный» объем ОЗУ (я считаю, что по умолчанию может быть 128 МБ), и это жесткое ограничение, которое ваше приложение не может превысить без сбоя. Профилируйте свое приложение с течением времени, настраивая параметры памяти на JVM, и узнайте, какой минимальный объем оперативной памяти вам понадобится для того, чтобы ваше приложение работало как (a) с приемлемой производительностью, так и (b) без выброса OutOfMemoryError , и все готово.
Ссылка: Как настроить параметры JVM и память?
Для других требований, таких как требование к процессору, все становится немного размытым. Существует много процессоров, и пропускная способность, которую производит данная система, может варьироваться не только в зависимости от скорости процессора, но и скорости жесткого диска, объема оперативной памяти, установленной в системе, скорости сетевого интерфейса ( если вы пишете сетевое приложение) и другие вещи. Для таких требований вы просто захотите протестировать его на различных системах и где-то провести черту и сказать: «Вы можете ожидать приемлемой производительности, если у вас есть оборудование, которое по крайней мере столь же мощно, как X, Y». , Z ".
Другая вещь, которую вы могли бы сделать, это встроить эталонный тест или что-то вроде регистрации производительности, и получить эти данные о производительности, отправленные вам обратно. Многие приложения делают это. Вы знаете, что «мы можем отправить анонимные данные об использовании обратно на корабль?» вопрос, который вы получаете при установке какого-либо программного обеспечения? Что ж, среди этих данных распространены сведения о системе, такие как ОЗУ, ЦП, модель жесткого диска и другие сведения об аппаратном обеспечении (какие бы данные вы ни указывали, относящиеся к вашему приложению), а также данные регистрации производительности. Используя такой подход, вы получаете множество данных о производительности от множества различных конфигураций системы без необходимости иметь огромное количество машин с различной конфигурацией.
Вы можете сделать то же самое для программных сбоев и ошибок - иметь следы стека, системную информацию и другие соответствующие данные, выгружаемые в файл журнала, который отправляется обратно вам - но, конечно, только если ваши пользователи сказал, что все в порядке , чтобы отправить эти данные обратно к вам.