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

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

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

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

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

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

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

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

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

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

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

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

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

R>Все время приходится на Виндоуз следить, чтобы реультирующее имя файла случайно не превысило 250 символов, потому как некоторые не связанные с Явой вещи (копирование в опред. обстоятельствах например) начинают глючить (как минимум на Виндоуз 2003 Сервер это еще так).
Раз уж пнули 2003ю: даже в Windows Server 2008R2 это так. Для ANSI версии WinAPI.
Начиная с 2000й (про NT уже не упомню со 100% уверенностью) путь в винде позволяет быть около 32К символов.
Просто многие программы жо сих пор про Unicode WinAPI ни ухом ни рылом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CC>>Просто многие программы жо сих пор про Unicode WinAPI ни ухом ни рылом.
PD>Для справедливости отмечу, что Юникодовский вариант с вопросом особого восторга у меня не вызывает.
Дык "он не деньги, чтоб всем нравиться" (С)

Привет всем,

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

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

Здравствуйте, 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 есть настоящие недостатки, а про структуру файлов это незначительная мелочь, которая расстраивает только первые два дня, где-то наравне с излишне мусорным синтаксисом.

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

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

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

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

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

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

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

Здравствуйте, 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 ничего не меняет), то это другой вопрос.

Здравствуйте, 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>Всего доброго.

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

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

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

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

AL>

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

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

Вы не замечате вопросительно знака в конце предложения? как и вопросительного контекста.


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

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

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

Это вы видимо в больших и многогранных проектах не участвовали и не знакомы с принципами

назад?
Остальные понты оставим на моей совести

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

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

М-м-м... Пардон, не понял... Винда не держит пути по 250 символов? Или у вас есть классы с именами такой длины? А как вы этого добились, если не секрет?

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

R>Остальные понты оставим на моей совести

Осталось понять, что речь шла о дотнетных сбоках ака assemblies, а не о CI.

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

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

R>>Остальные понты оставим на моей совести

AVK>Осталось понять, что речь шла о дотнетных сбоках ака assemblies, а не о CI.

Мне показалось, что серьезный программист на .NET разбирается в assemblies настолько, что отдельный "специалист по assembly" не требуется. Что бы таковой делал? Консультривал коллег по сборкам?
Поэтому логично было предположить, что речь идет о "сборке проекта" со слежением за версиями, зависимостями и пр.

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

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

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

П>М-м-м... Пардон, не понял... Винда не держит пути по 250 символов? Или у вас есть классы с именами такой длины? А как вы этого добились, если не секрет?

Винда-то какбэ держит. Проблемы возникают даже просто в Эксплорере при попытке работать с такими глубокими каталогами.

А получить такой длинный путь Ява позволяет элементарно. Сначала не экономьте на длинне названий ваших пакетов, потом иногда такие пути вкладываются друг в друга (ну там например статические файлы в Эклипс-плагине, который сам находится верятно в проекте эклипс-плагина с длинным путем файла.
Теперь спереди добавьте структуру каталогов вашего воркспейса сорс-контрол системы. А теперь например попробуйте скопировать все это от корня в каку-нибдь свою удобную бэкап папку, ну положим в "Мои Документы", или во временную папку используемую билдом для сборки.
И незаметите, как будете недоумевать, почему папка не копируется командной строкой или не удаляется даже через Эксплорер.

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

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

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

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

По моему это хорошая вещь. Всегда известно где искать. Это многократно окупает небольшой геморой с размещением.
А вот если искать не надо — тогда да, можно как угодно хранить.

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

CC>Просто многие программы жо сих пор про Unicode WinAPI ни ухом ни рылом.

Для справедливости отмечу, что Юникодовский вариант с вопросом особого восторга у меня не вызывает.

The Windows API has many functions that also have Unicode versions to permit a maximum path length of approximately 32,000 characters composed of components up to 255 characters each in length. To specify that kind of extended length path, use the "\\?\" prefix. For example, "\\?\D:\<path>".