Привет всем,

Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета.
То же самое должно соблюдаться для расположения скомпилированных класс-файлов.

Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?

R>Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета.
R>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.

R>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
R>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?

Это цвет сарая для велосипедов.
http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality

Допустим, программист вообще не вылезал из IDE. Он мог бы вообще не знать о существовании каких-то файлов, папок и путей.
В Java есть настоящие недостатки, а про структуру файлов это незначительная мелочь, которая расстраивает только первые два дня, где-то наравне с излишне мусорным синтаксисом.

Здравствуйте, Temoto, Вы писали:

R>>Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета.
R>>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.

R>>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
R>>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?

T>Это цвет сарая для велосипедов.
T>http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality

T>Допустим, программист вообще не вылезал из IDE. Он мог бы вообще не знать о существовании каких-то файлов, папок и путей.
T>В Java есть настоящие недостатки, а про структуру файлов это незначительная мелочь, которая расстраивает только первые два дня, где-то наравне с излишне мусорным синтаксисом.

Полностью разделяю идею Паркинсона. Аналогия впрочем неуместна, поскольку вопрос не из области "что можно усовершенствовать в Яве" и даже не из области "недостатки Явы".
Меня интересует исключительно одна особенность.
Существуют люди, считающие применение вложенных папок удобством в Яве. Мне интересно, насколько распространено такое мнение.

Дело в том, что идея наложить ограничения на имена файлов и заставить пользователей вручную создавать сложные структуры папок, приходит некоторым в процессе разработки прикладных приложений, не относящихся средам программирования. В качестве аргумента в пользу сложного решения приводится пример Явы (мне все же кажется, что настоящий аргумент -- подкупающее упрощение реализации).

Вот я и спрашиваю, действительно ли много-папочность в Яве это ее преимущество (безотносительно к важности этого достоинства/недостатка в Яве).

Здравствуйте, Temoto, Вы писали:

R>>Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета.
R>>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.

R>>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
R>>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?

T>Это цвет сарая для велосипедов.
T>http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality

T>Допустим, программист вообще не вылезал из IDE. Он мог бы вообще не знать о существовании каких-то файлов, папок и путей.
T>В Java есть настоящие недостатки, а про структуру файлов это незначительная мелочь, которая расстраивает только первые два дня, где-то наравне с излишне мусорным синтаксисом.

Или вы какбэ намекаете, что если в предмете обсуждения разбирается больше одного человека, то следует принимать первое попавшееся может быть не самое дальновидное решение, чтобы не впадать в дискуссию о сарае? (Я говорю не о Яве, см. соседний пост)
Накопленная погрешность от таких решений может потом незаметно погубить проект, при этом каждое отдельное решение никем не воспринимается как причина провала.

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

Интересно, как же определить, что следует обсуждать, а что нет?

Здравствуйте, Rothmans, Вы писали:

R>Вот я и спрашиваю, действительно ли много-папочность в Яве это ее преимущество (безотносительно к важности этого достоинства/недостатка в Яве).
Нет, это просто её особенность.

Как программист на Java, C++, C# и других языках, требования соответствия путей и пакета — это ТАКАЯ МЕЛОЧЬ по сравнению с остальным.

Здравствуйте, Rothmans, Вы писали:

R>Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета.

Вообще-то нет.

R>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?

По мне — преимущество, т.к. делает проект более предсказуемым и менее зависимым от тараканов в голове у конкретных занимающихся им программистов.

Здравствуйте, Пацак, Вы писали:

R>>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?

П>По мне — преимущество, т.к. делает проект более предсказуемым и менее зависимым от тараканов в голове у конкретных занимающихся им программистов.

Спасибо, за ответ по теме

Здравствуйте, Cyberax, Вы писали:

C>Как программист на Java, C++, C# и других языках, требования соответствия путей и пакета — это ТАКАЯ МЕЛОЧЬ по сравнению с остальным.

Повторюсь: вопрос не о Яве и не о языках программирования. Вопрос, я бы сказал, об аргументации ява-подобного решения в прикладной программе.
Ответ, видимо, зависит от потребителя данного решения.
Для автоматической обработки проргаммой, мета-информацию до определенной степени, наверное, можно хранить в имени файла.
Требовать от пользователя ручного соблюдения сложных условий наименования, все же мне кажется недостатком для пользователя.

Здравствуйте, Rothmans, Вы писали:

R>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
R>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?

Ответ на первый вопрос: у Java нет такого требования. Своим classloader-ом можно грузить классы хоть из космоса.
Ответ на второй вопрос: может быть и да, поскольку бардак на столе или в комнате иногда позволяет быстро находить какую-нибудь часто используемую вещь, лежащую на самом видном месте.

Здравствуйте, A.Lokotkov, Вы писали:

AL>Здравствуйте, Rothmans, Вы писали:

R>>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
R>>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?

AL>Ответ на первый вопрос: у Java нет такого требования. Своим classloader-ом можно грузить классы хоть из космоса.

А как вы практически создаете класс, для загрузки "из космоса"? Структуру каталогов не соблюдаете?
(Мне знаком принцип отделения средства хранения исходных текстов от стандарта языка, но мы же все хорошо понимаем, о чем идет речь)

AL>Ответ на второй вопрос: может быть и да, поскольку бардак на столе или в комнате иногда позволяет быстро находить какую-нибудь часто используемую вещь, лежащую на самом видном месте.

А если в понедельник удобно находить мусор на столе по имени пакета, а в среду по зависимосям между ними, а в пятницу по версии или размеру.
Вы собираетесь все эти свойства запихивать в имена каталогов и файлов ваших исходных файлов?
Вы считаете манифесты неудобством, потому что их содержимое не является частью имени файла?

Здравствуйте, Rothmans, Вы писали:

R>А как вы практически создаете класс, для загрузки "из космоса"? Структуру каталогов не соблюдаете?
R>(Мне знаком принцип отделения средства хранения исходных текстов от стандарта языка, но мы же все хорошо понимаем, о чем идет речь)

Соблюдаю структуру пакетов, которая естественным образом отображается на иерархию путей в пределах локальной/удаленной файловой системы, в пределах одного или нескольких jar-ов и т.д.

R>А если в понедельник удобно находить мусор на столе по имени пакета, а в среду по зависимосям между ними, а в пятницу по версии или размеру.
R>Вы собираетесь все эти свойства запихивать в имена каталогов и файлов ваших исходных файлов?

Нет, не собираюсь. Поскольку в Java-проектах до 500 KSLOC пока не имел таких проблем. А вот в небольшой build-системе, написанной в виде AddIn-а к MSVS на C#, при переходе от одной версии студии к другой -- да, замахался правильные версии сборок подставлять.

R>Вы считаете манифесты неудобством, потому что их содержимое не является частью имени файла?

Нет, не считаю, тем более что манифест был в jar-ах, когда .NET еще пешком под стол не ходил. Но считаю абсурдом иметь в C#-проекте отдельную роль "специалист по сборкам", каковую довелось видеть в соседнем подразделении.

Здравствуйте, Rothmans, Вы писали:

R>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.

Вот именно. Для других языков это требование попросту отсутствует, кладите свой EXE куда хотите, он один. А для Java, коль скоро необходимо это требование выполнять, то и для исходников логично то же требование.

Здравствуйте, A.Lokotkov, Вы писали:

R>>Вы считаете манифесты неудобством, потому что их содержимое не является частью имени файла?

AL>Нет, не считаю, тем более что манифест был в jar-ах, когда .NET еще пешком под стол не ходил. Но считаю абсурдом иметь в C#-проекте отдельную роль "специалист по сборкам", каковую довелось видеть в соседнем подразделении.

Вообще-то я не собирался сравнивать Яву с С#
Но мимо последнего ваше замечания насчет ненужности "специалиста по сборкам" не смог пройти мимо
Это вы видимо в больших и многогранных проектах не участвовали и не знакомы с принципами менеджмента конфигураций.
Когда у вас 20+ проектов, использующих 3-5 разных базовых технологий. И надо придерживаться ISO и местных Agile правил. И все вместе надо минимум 2 раза в неделю собирать и чтобы любой билд был зафиксирован в Agile и его можно было зарепродьюсить. И при этом разработчики сидят в часовых поясах с раностью в 9 часов
Я слабо представляю, как в такой ситуации можно обойтись без "специалиста по сборкам".

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Rothmans, Вы писали:

R>>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.

PD>Вот именно. Для других языков это требование попросту отсутствует, кладите свой EXE куда хотите, он один. А для Java, коль скоро необходимо это требование выполнять, то и для исходников логично то же требование.

Согласен, логично. Не неудобно же, по сравнению с другими средами, которые позволяют класть что угодно куда угодно при желании.
На самом деле, на мой взгляд, самый большой недостаток малозначительной много-папочности в Яве это те миллионы кликов по папкам которые так или иначе (не все же вы буквально в жизни делаете в IDE) тратятся человечеством при разработке на Ява. С мира по нитке -- нищему сорочка (утечка производительности).

Но этот вопрос, я согласен, из разряда покраски сарая.

Обоснование применения того же принципа в коммерческом прикладном продукте примером Явы -- уже не такой уж и вопрос о сарае.

А вот мне кстати вспомнился вполне осязаемый недостаток много-папочности.
Все время приходится на Виндоуз следить, чтобы реультирующее имя файла случайно не превысило 250 символов, потому как некоторые не связанные с Явой вещи (копирование в опред. обстоятельствах например) начинают глючить (как минимум на Виндоуз 2003 Сервер это еще так).
Вы скажете, что это недостаток Виндоуз. А я скажу, что Виндоуз требует кастомер, и он не собирается переходить на что-либо другое из-за длинных имен файлов, которых он и не заказывал.

Здравствуйте, Rothmans, Вы писали:

PD>>Вот именно. Для других языков это требование попросту отсутствует, кладите свой EXE куда хотите, он один. А для Java, коль скоро необходимо это требование выполнять, то и для исходников логично то же требование.

R>Согласен, логично. Не неудобно же, по сравнению с другими средами, которые позволяют класть что угодно куда угодно при желании.

Когда это "что угодно" есть 1 файл, то можно его и класть куда угодно. Когда же файлов сотни и тысячи, то без какой-то архитектуры не обойтись. Придумывать еще одну — вряд ли имеет смысл.
Ну а что касается того, что в Яве каждый файл компилируется в свой файл .class и они все вместе поставляются (jar ничего не меняет), то это другой вопрос.

Здравствуйте, Rothmans, Вы писали:

R>Вообще-то я не собирался сравнивать Яву с С#

Я и не утверждал, что Вы собираетесь сравнивать или сравниваете. И сам тоже не сравниванию, кстати. Там, просто-напросто, был симметричный ответ на Ваши домыслы по поводу того, что я, якобы, считаю манифест неудобством.

R>Но мимо последнего ваше замечания насчет ненужности "специалиста по сборкам" не смог пройти мимо
R>Это вы видимо в больших и многогранных проектах не участвовали и не знакомы с принципами менеджмента конфигураций.
R>Когда у вас 20+ проектов, использующих 3-5 разных базовых технологий. И надо придерживаться ISO и местных Agile правил. И все вместе надо минимум 2 раза в неделю собирать и чтобы любой билд был зафиксирован в Agile и его можно было зарепродьюсить. И при этом разработчики сидят в часовых поясах с раностью в 9 часов
R>Я слабо представляю, как в такой ситуации можно обойтись без "специалиста по сборкам".

О да, конечно же нигде не участвовал и ни с чем не знаком . Поэтому мне будет простительно не понимать, как соотнести отдельного специалиста по дотнетным сборкам со всеми этими страшно крутыми словами: Agile, ISO, 20+/3-5 базовых технологий.

Всего доброго.

Здравствуйте, A.Lokotkov, Вы писали:

AL>Здравствуйте, Rothmans, Вы писали:

R>>Вообще-то я не собирался сравнивать Яву с С#

AL>Я и не утверждал, что Вы собираетесь сравнивать или сравниваете. И сам тоже не сравниванию, кстати. Там, просто-напросто, был симметричный ответ на Ваши домыслы по поводу того, что я, якобы, считаю манифест неудобством.

Прошу прощения, если мой вопрос показался Вам домыслом.

R>>Но мимо последнего ваше замечания насчет ненужности "специалиста по сборкам" не смог пройти мимо
R>>Это вы видимо в больших и многогранных проектах не участвовали и не знакомы с принципами менеджмента конфигураций.
R>>Когда у вас 20+ проектов, использующих 3-5 разных базовых технологий. И надо придерживаться ISO и местных Agile правил. И все вместе надо минимум 2 раза в неделю собирать и чтобы любой билд был зафиксирован в Agile и его можно было зарепродьюсить. И при этом разработчики сидят в часовых поясах с раностью в 9 часов
R>>Я слабо представляю, как в такой ситуации можно обойтись без "специалиста по сборкам".

AL>О да, конечно же нигде не участвовал и ни с чем не знаком . Поэтому мне будет простительно не понимать, как соотнести отдельного специалиста по дотнетным сборкам со всеми этими страшно крутыми словами: Agile, ISO, 20+/3-5 базовых технологий.

AL>Всего доброго.

Ну ну, не расстраивайтесь, я не хотел Вас обидеть, специально заменял крутые слова безграмотным сленгом

Здравствуйте, Rothmans, Вы писали:

R>Прошу прощения, если мой вопрос показался Вам домыслом...

Вы считаете манифесты неудобством, потому что их содержимое не является частью имени файла?

Мне, да еще и показался ? Прекрасный полемический ход.

R>Ну ну, не расстраивайтесь, я не хотел Вас обидеть, ...

А можно я немного порасстраиваюсь и пообижаюсь? Спасибо.

Здравствуйте, Rothmans, Вы писали:

R>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.
На расположение бинарей наплевать.

R>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
По мне так это крайне неудобно. Как и правило один класс — один файл.

R>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?
Да!