История изменений
Исправление DarkAmateur, (текущая версия) :
А чего ты решил, что в java проектах не будет ос-специфичного кода?
Это уже тонкие вопросы архитектуры проекта, а не платформы в целом.
И что тестирование на разных версиях ос в обязанности группы разработки не входит?
Формально входит, но в Java экосистеме с гораздо более низким приоритетом и более щадящем режиме, т.к. ожидаемый результат во многом предсказуем.
И исходя из этого чем оттестированное приложение на не-java-языке отличается по надежности от java?
Как пример, приложение на ANSI C (кроссплатформенность на уровне сырцов), может быть собрано с GLIBC, а может с Musl, потому что кто-то вдруг захотел контейнер. Туда же, Rust под MSVC и GCC, Python/PyPy +/- Nuitka с батарейками на C... Кто знает, что там стрельнёт внутри без полноценного тестирования?
Исправление DarkAmateur, :
А чего ты решил, что в java проектах не будет ос-специфичного кода?
Это уже тонкие вопросы архитектуры проекта, а не платформы в целом.
И что тестирование на разных версиях ос в обязанности группы разработки не входит?
Формально входит, но в Java экосистеме с гораздо более низким приоритетом и более щадящем режиме, т.к. ожидаемый результат во многом предсказуем.
И исходя из этого чем оттестированное приложение на не-java-языке отличается по надежности от java?
Как пример, приложение на ANSI C (кроссплатформенность на уровне сырцов), может быть собрано с GLIBC, а может с Musl, потому что кто-то вдруг захотел контейнер. Туда же, Rust под MSVC и GCC, Python с батарейками на C... Кто знает, что там стрельнёт внутри без полноценного тестирования?
Исправление DarkAmateur, :
А чего ты решил, что в java проектах не будет ос-специфичного кода?
Это уже тонкие вопросы архитектуры проекта, а не платформы в целом.
И что тестирование на разных версиях ос в обязанности группы разработки не входит?
Формально входит, но в Java экосистеме с гораздо более низким приоритетом и более щадящем режиме, т.к. ожидаемый результат во многом предсказуем.
И исходя из этого чем оттестированное приложение на не-java-языке отличается по надежности от java?
Как пример, приложение на ANSI C (кроссплатформенность на уровне сырцов), может быть собрано с GLIBC, а может с Musl, потому что кто-то вдруг захотел контейнер. Туда же, Rust под MSVC и GCC. Python с батарейками на C... Кто знает, что там стрельнёт внутри без полноценного тестирования?
Исправление DarkAmateur, :
А чего ты решил, что в java проектах не будет ос-специфичного кода?
Это уже тонкие вопросы архитектуры проекта, а не платформы в целом.
И что тестирование на разных версиях ос в обязанности группы разработки не входит?
Формально входит, но в Java экосистеме с гораздо более низким приоритетом и более щадящем режиме, т.к. ожидаемый результат во многом предсказуем.
И исходя из этого чем оттестированное приложение на не-java-языке отличается по надежности от java?
Как пример, приложение на ANSI C (кроссплатформенность на уровне сырцов), может быть собрано с GLIBC, а может с Musl, потому что кто-то вдруг захотел контейнер. Туда же, Rust под MSVC и GCC. Python с батарейками на C...
Исправление DarkAmateur, :
А чего ты решил, что в java проектах не будет ос-специфичного кода?
Это уже тонкие вопросы архитектуры проекта, а не платформы в целом.
И что тестирование на разных версиях ос в обязанности группы разработки не входит?
Формально входит, но в Java экосистеме с гораздо более низким приоритетом и более щадящем режиме, т.к. ожидаемый результат во много предсказуем.
И исходя из этого чем оттестированное приложение на не-java-языке отличается по надежности от java?
Как пример, приложение на ANSI C (кроссплатформенность на уровне сырцов), может быть собрано с GLIBC, а может с Musl, потому что кто-то вдруг захотел контейнер. Туда же, Rust под MSVC и GCC. Python с батарейками на C...
Исправление DarkAmateur, :
А чего ты решил, что в java проектах не будет ос-специфичного кода?
Это уже тонкие вопросы архитектуры проекта, а не платформы в целом.
И что тестирование на разных версиях ос в обязанности группы разработки не входит?
Формально входит, но в Java экосистеме с гораздо более низким приоритетом и более щадящем режиме, т.к. ожидаемый результат во много предсказуем.
И исходя из этого чем оттестированное приложение на не-java-языке отличается по надежности от java?
Как пример, приложение на ANSI C (кроссплатформенность на уровне сырцов), может быть собрано с GLIBC, а может с Musl, потому что кто-то вдруг захотел контейнер.
Исходная версия DarkAmateur, :
А чего ты решил, что в java проектах не будет ос-специфичного кода?
Это уже тонкие вопросы архитектуры проекта, а не платформы в целом.
И что тестирование на разных версиях ос в обязанности группы разработки не входит?
Формально входит, но в Java экосистеме с гораздо более низким приоритетом и более щадящем режиме, т.к. ожидаемый результат во много предсказуем.
И исходя из этого чем оттестированное приложение на не-java-языке отличается по надежности от java?
Как пример, приложение на ANSI C, может быть собрано с GLIBC, а может с Musl, потому что кто-то вдруг захотел контейнер.